FR2821458A1 - Schema, procede d'analyse syntaxique et procede de generation d'un flux binaire a partir d'un schema - Google Patents

Schema, procede d'analyse syntaxique et procede de generation d'un flux binaire a partir d'un schema Download PDF

Info

Publication number
FR2821458A1
FR2821458A1 FR0102764A FR0102764A FR2821458A1 FR 2821458 A1 FR2821458 A1 FR 2821458A1 FR 0102764 A FR0102764 A FR 0102764A FR 0102764 A FR0102764 A FR 0102764A FR 2821458 A1 FR2821458 A1 FR 2821458A1
Authority
FR
France
Prior art keywords
xsd
num
data
type
name
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
FR0102764A
Other languages
English (en)
Inventor
Sylvain Devillers
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Koninklijke Philips NV
Original Assignee
Koninklijke Philips Electronics NV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Koninklijke Philips Electronics NV filed Critical Koninklijke Philips Electronics NV
Priority to FR0102764A priority Critical patent/FR2821458A1/fr
Priority to BR0204315-7A priority patent/BR0204315A/pt
Priority to KR1020027014532A priority patent/KR100898614B1/ko
Priority to RU2003128962/09A priority patent/RU2294012C2/ru
Priority to PCT/IB2002/000393 priority patent/WO2002069187A1/fr
Priority to EP02710247A priority patent/EP1366439A1/fr
Priority to US10/258,924 priority patent/US7080318B2/en
Priority to MXPA02010534A priority patent/MXPA02010534A/es
Priority to JP2002568241A priority patent/JP4260481B2/ja
Priority to CNB028014421A priority patent/CN100449530C/zh
Priority to PL02363513A priority patent/PL363513A1/xx
Priority to TW091103306A priority patent/TW563036B/zh
Publication of FR2821458A1 publication Critical patent/FR2821458A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/958Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • G06F16/986Document structures and storage, e.g. HTML extensions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25Integrating or interfacing systems involving database management systems
    • G06F16/258Data format conversion from or to a database

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Document Processing Apparatus (AREA)
  • Compression, Expansion, Code Conversion, And Decoders (AREA)

Abstract

L'invention propose un nouveau genre de schéma dérivé dé XML-schema qui permet de décrire de façon générique un format de codage. Un tel schéma est utilisé pour procéder à l'analyse syntaxique d'un flux binaire afin de produire un document représentant le flux binaire qui est une instance dudit schéma, ou pour générer un flux binaire à partir d'un document le représentant.Application : édition, modification, fusion de contenu.

Description

<Desc/Clms Page number 1>
DESCRIPTION
Figure img00010001

Domaine de l'invention La présente invention concerne un procédé d'analyse syntaxique d'un flux binaire contenant des données qui ont une structure et un contenu conformes à un certain format, pour générer une représentation arborescente dudit flux. Elle concerne aussi un procédé de génération d'un flux binaire conforme à un certain format, à partir d'un document qui est une représentation arborescente dudit flux binaire et qui contient des données, notamment des données importées en utilisant un certain mode d'importation. Elle concerne aussi un schéma définissant un ou plusieurs type (s) de données susceptible (s) d'avoir une ou plusieurs facette (s), et comportant une pluralité d'éléments pour lesquels il décrit un nom, un type de données, une imbrication, un ordre et un nombre d'occurrence (s) prédéfinis ou quelconques, l'occurrence d'un élément étant obligatoire ou optionnelle.
L'invention concerne également des programmes d'ordinateur pour la mise en oeuvre de tels procédés, une unité de traitement qui contient des moyens de stockage d'un tel schéma et d'un ou de tels programmes d'ordinateur, ainsi qu'un système de transmission qui comporte au moins une entité source et une entité destination, ladite entité source contenant des moyens de stockage d'un tel schéma et d'un ou de tels programmes.
Figure img00010002
L'invention a des applications dans le domaine de l'édition, déjà modification, de la fusion de contenu.
Un exemple d'application de l'invention est l'adaptation d'un contenu à transmettre à un destinataire en fonction du profile de l'utilisateur (écran, capacité de calcul, capacité de stockage, liaison utilisée pour la transmission...). Une telle adaptation permet notamment d'éviter de transmettre inutilement des données qui ne pourront pas être utilisées par le destinataire, et donc d'économiser de la bande passante.
Arrière plan technoloqique de l'invention
Figure img00010003

A cet égard, la demande de brevet français no 0101530 déposée le 05. 02. 2001 par la société Koninklijke Philips Electronics N. V. a déjà décrit un procédé de génération d'un fichier ayant certaines caractéristiques, à partir d'un document de base écrit dans un langage de balisage et décrivant un fichier progressif de base, ledit procédé comportant une étape de transformation pour générer un document transformé en appliquant au document de base une transformation prédéfinie qui est fonction desdites caractéristiques, le fichier ayant lesdites caractéristiques étant généré à partir du document transformé. Ce procédé consiste à effectuer les transformations nécessaires sur un document de base dans lequel la structure du fichier progressif est apparente. Il permet d'éviter d'avoir à décoder le fichier progressif de base pour le ré-encoder différemment.
<Desc/Clms Page number 2>
Toutefois ce procédé de génération de fichier implique de générer un document de base qui décrit le fichier progressif de base, puis de générer un autre fichier à partir du document transformé.
Résumé de l'invention
La présente invention a pour but de proposer une méthode automatique et générique
Figure img00020001

pour effectuer de telles opérations.
Pour cela, l'invention consiste notamment à proposer un nouveau genre de schéma qui permet de décrire un format de codage de façon générique.
Un schéma selon l'invention définit un ou plusieurs type (s) de données susceptible (s) d'avoir une ou plusieurs facette (s). Il comporte une pluralité d'éléments pour lesquels il décrit un nom, un type de données, une imbrication, un ordre et un nombre d'occurrence (s) prédéfinis ou quelconques, l'occurrence d'un élément étant obligatoire ou optionnelle. Et il est caractérisé en ce qui) a au moins l'une des caractéristiques suivantes : - il définit un type de données qui correspond à des segments binaires de longueur indéfinie et qui a au moins une facette relative à un mode d'importation de données, et optionnellement une facette relative à un drapeau de fin de segment binaire, - il définit un ou plusieurs types de données qui correspondent à des mots binaires de longueur (s) prédéfinie (s) et qui ont au moins une facette relative à ladite longueur et, optionnellement une facette relative à des bits de remplissage contenus dans lesdits mots binaires, - il définit une ou plusieurs variable (s) constituée (s) par un chemin d'accès à des données et il comporte un ou plusieurs branchement (s) conditionnel (s) pour décrire différentes structures ou contenus possibles en fonction de la valeur de la ou desdites variables.
Un procédé selon l'invention d'analyse syntaxique d'un flux binaire contenant des données qui ont une structure et un contenu conforme à un certain format, pour générer une représentation arborescente dudit flux, est caractérisé en ce que ledit procédé consiste à utiliser un schéma qui, pour décrire ledit format de façon générique : a) définit un ou plusieurs type (s) de données, susceptible (s) de contenir une ou plusieurs facette (s), dont notamment : - lorsque ledit format utilise des mots binaires de longueur (s) prédéfinie (s), un ou plusieurs types de données correspondant aux dits mots binaires de longueur (s) prédéfinie (s), ayant au moins une facette relative à ladite longueur et, lorsque lesdits mots binaires de longueur (s) prédéfinie (s) sont susceptibles de contenir un ou plusieurs bit (s) de remplissage, une facette relative aux dits bits de remplissage, - lorsque ledit format utilise des segments binaires de longueur indéfinie ayant un contenu destiné à être importé dans ladite représentation en utilisant un certain mode d'importation, un type de données correspondant aux dits segments binaires, ayant au moins une facette relative audit mode d'importation et, lorsque lesdits segments binaires sont délimités par un drapeau de
<Desc/Clms Page number 3>
fin, une facette relative audit drapeau de fin, b) comporte une pluralité d'éléments pour lesquels il décrit un nom, un type de données, une imbrication, un ordre et un nombre d'occurrence (s) prédéfinis ou quelconques, l'occurrence d'un élément étant obligatoire ou optionnelle, c) lorsque ledit format prévoit que des données situées en amont dans ledit flux binaire
Figure img00030001

informent sur la structure ou le contenu de la suite dudit flux binaire, - définit une ou plusieurs variable (s) constituée (s) par-un chemin d'accès aux dites données situées en amont, dans ladite représentation arborescente, - et comporte un ou plusieurs branchement (s) conditionnel (s) pour décrire les différentes structures ou contenus possibles en fonction de la valeur de la ou desdites variables, ladite représentation arborescente étant une instance dudit schéma.
L'invention consiste donc à fournir un outil qui permet de décrire un format de façon générique dans un schéma. Elle consiste ensuite à utiliser un tel schéma pour analyser la syntaxe d'un flux binaire conforme audit format afin de générer un document qui représente ledit flux et qui est une instance dudit schéma. Le schéma spécifie les différents types de données susceptibles d'être contenues dans un flux binaire conforme audit format, ainsi que la façon d'inclure ces données dans le document final. Les types de données spécifiés dans le schéma, et les règles d'inclusion dans le document final dépendent du format considéré.
Figure img00030002
A titre d'exemple, lorsque le format considéré est le format JPEG2000 (norme ISO/IEC FCD15444-1), ledit schéma : - définit plusieurs types de données qui correspondent à mots binaires de longueurs prédéfinies susceptibles de comporter des bits de remplissage, et qui ont une facette relative à ladite longueur et une ou plusieurs facette (s) relative (s) aux dits bits de remplissage, - définit un type de données qui correspond à des segments binaires de longueur indéfinie, délimités par un drapeau de fin et ayant un contenu destiné à être importé dans ladite représentation en utilisant un certain mode d'importation, et qui a une facette relative à un mode d'importation et une facette relative audit drapeau de fin, - définit une ou plusieurs variable (s) constituée (s) par un chemin d'accès, dans ladite représentation arborescente, à des données situées en amont dans ledit flux binaire et qui informent sur la structure ou le contenu de la suite dudit flux binaire, - et comporte un ou plusieurs branchement (s) conditionnel (s) pour décrire les différentes structures ou contenus possibles en fonction de la valeur de la ou desdites variables.
Un procédé selon l'invention de génération d'un flux binaire conforme à un certain format, à partir d'un document qui est une représentation arborescente dudit flux binaire et qui contient des données, notamment des données importées en utilisant un certain mode d'importation, est caractérisé en ce qui) consiste à utiliser un schéma qui, pour décrire ledit format le façon générique : a) définit un ou plusieurs type (s) de données susceptible (s) d'avoir une ou plusieurs facette (s), notamment :
<Desc/Clms Page number 4>
- un type de données correspondant à des segments binaires de longueur indéfinie ayant au moins une facette relative audit mode d'importation, - et, lorsque ledit format utilise des mots binaires de longueur (s) prédéfinie (s), un ou plusieurs types de données correspondant aux dits mots binaires de longueur (s) prédéfinie (s) ayant au moins une facette relative à ladite longueur, et lorsque lesdits mots binaires contiennent un ou plusieurs bit (s) de remplissage, une facette relative aux dits bits de remplissage, b) comporte une pluralité d'éléments pour lesquels il décrit un nom, un type de données, une imbrication, un ordre et un nombre d'occurrence (s) prédéfinis ou quelconques, l'occurrence d'un élément étant obligatoire ou optionnelle, c) lorsque ledit format prévoit que des données situées en amont dans ledit flux binaire
Figure img00040001

informent sur la structure ou le contenu de la suite dudit flux binaire : - définit une ou plusieurs variable (s) constituée (s) par un chemin d'accès aux dites données situées en amont, dans ladite représentation arborescente, - et comporte un ou plusieurs branchement (s) conditionnel (s) pour décrire les différentes structures ou contenus possibles en fonction de la valeur de la ou desdites variables,
Figure img00040002

ledit procédé consistant à lire en parallèle ledit document et ledit schéma pour déterminer le type des données contenues dans ledit document, à coder lesdites données en fonction du type déterminé, et à constituer un flux binaire à partir des données codées.
L'invention consiste donc aussi à utiliser un schéma du type décrit plus haut pour générer un flux binaire à partir d'un document qui le représente et qui est une instance dudit schéma. Le document et le schéma sont lus en parallèle pour déterminer le type des données contenues dans le document, afin de les coder conformément à ce que prévoit ledit format, et à constituer un flux binaire avec les données codées.
Brève description des dessins - la figure 1 représente un schéma en blocs résumant le principe de fonctionnement d'un procédé d'analyse syntaxique selon l'invention, - la figure 2 représente un schéma en blocs résumant le principe de fonctionnement d'un procédé de génération d'un flux binaire selon l'invention, - la figure 3 est un exemple d'un système de transmission selon l'invention.
Description d'un mode de réalisation préférentiel
Sur la figure 1, on a représenté un schéma en blocs exposant le principe de fonctionnement d'un procédé d'analyse syntaxique selon l'invention. Un bloc B1 représente un flux binaire conforme à un format prédéterminé. Un bloc B2 représente un schéma qui décrit ledit format prédéterminé de façon générique. Un bloc B3 représente un analyseur syntaxique permettant de faire une analyse syntaxique du flux B1 pour générer un document B4 qui est une représentation arborescente du flux binaire B1 et une instance du schéma B2.
<Desc/Clms Page number 5>
Le schéma B2 décrit la syntaxe du flux binaire. Il spécifie notamment le type des données susceptibles d'être rencontrées dans le fichier binaire, et la façon dont elles doivent être indes dans le document. La représentation arborescente B4 est générée au fur et à mesure de l'analyse du flux binaire Bl.
Sur la figure 2, on a représenté un schéma en blocs exposant le principe de fonctionnement d'un procédé de génération d'un flux binaire selon l'invention. Un bloc B'2 représente un schéma qui décrit un format de codage de façon générique. Un bloc B'4
Figure img00050001

représente un document qui est une instance du schéma B'2. Un bloc B'3 représente un générateur de flux binaire permettant de lire en parallèle le document B'4 et le schéma B'2 pour générer un flux binaire B'1. Avantageusement les schémas B2 et B'2 utilisés pour un même format de codage sont identiques.
Le document B'4 est lu avec le schéma B'2 de façon à déterminer le type des données qui sont contenues dans le document B'4. Pour une valeur lue dans le document B'4, le type de données correspondant, trouvé dans le schéma B'2, détermine le mode de codage à utiliser pour coder ladite valeur.
D'une façon générale, il n'est pas forcément nécessaire de détailler complètement la structure du format de codage dans le schéma. Le niveau de détail dépend de l'application
Figure img00050002

envisagée. Pour l'application décrite dans la demande de brevet français nO 0101530 déjà citée dans l'introduction de la présente demande (procédé de génération d'tun fichier-par exemple d'un fichier JPEG 2000-ayant des caractéristiques adaptées au profil du destinataire), certains segments de marqueurs JPEG 2000 doivent être détaillés paramètre par paramètre pour permettre de récupérer lesdits paramètres et de les modifier. D'autres segments de marqueurs sont traités comme un bloc, parce qu'il n'est pas nécessaire d'accéder aux paramètres qu'ils contiennent.
De façon avantageuse, les documents B4 et B'4 sont des documents XML, et les schémas B2 et B'2 sont écrits dans un nouveau langage dérivé du langage XML-schema. XML est une recommandation du consortium W3C (eXtensible Markup Language 1.0 en date du 06.10. 2000), et XML-schema est un projet de recommandation du même consortium W3C daté du 24.10. 2000. La recommandation XML et le projet de recommandation XML-Schema sont disponibles sur le site Internet http : //www. w3. org/. Toutefois ceci n'est pas restrictif, et les
Figure img00050003

principes de l'invention qui vont être décrits en détails dans la suite de la description peuvent être mis en oeuvre en utilisant des langages d'un autre genre, par exemple des langages du genre DSD (de l'anglais Document Structure Description) proposé par AT & T et par BRICS de l'université d'Aarhus au Danemark et disponible sur le site Internet http ://www. brics. dk/DSD/.
D'un point de vue physique, un document XML comporte notamment des entités analysables qui contiennent du texte, c'est-à-dire une suite de caractères appartenant à un ensemble de caractères prédéfini, et qui représentent du balisage ou des données textuelles.
D'un point de vue logique, un document XML contient un ou plusieurs éléments dont les limites sont marquées par une balise ouvrante et une balise fermante. Des éléments peuvent
<Desc/Clms Page number 6>
s'imbriquer les uns dans les autres. Chaque élément est identifié par un nom qui est indiqué dans sa balise ouvrante et dans sa balise fermente. Un élément peut avoir une valeur. La valeur d'un élément est placée entre sa balise ouvrante et sa balise fermante.
Dans l'exemple qui va être décrit ci-dessous, afin de simplifier l'implémentation, on a choisit de placer les données directement dans les éléments du document XML (c'est-à-dire que les données contenues dans le document XML constituent des valeurs d'éléments XML).
XML-schema est un langage de schéma qui permet de spécifier le contenu et la structure de documents XML : en particulier un schéma XML permet de décrire des éléments, et pour chaque élément un nom, un type de données, une imbrication, un ordre d'apparition et un nombre d'occurrence (s). L'ordre d'apparition et le nombre d'occurrences peuvent être prédéfinis ou quelconques. L'occurrence d'un élément peut être obligatoire ou optionnelle.
Un schéma définit une classe de documents XML. Une instance d'un schéma XML est un document XML qui est valide par rapport audit schéma
Dans la suite de la description, et afin de donner un exemple concret de mise en oeuvre de l'invention, on va considérer des flux binaires au format JPEG 2000. Ceci n'est pas non plus restrictif, et il est clair que l'invention est applicable à d'autres formats. Pour certains formats, il peut être nécessaire d'ajouter d'autres types de données à ceux qui sont décrits ici.
On donne dans l'annexe A un exemple de schéma décrivant le format de codage JPEG 2000. Ce schéma utilise des types simples de données qui sont génériques et qui sont définis dans l'annexe B, et des types simples de données, dérivés de ces types génériques, qui sont définis dans l'annexe C. L'annexe D donne un exemple de document XML qui est une instance du schéma donné à l'annexe A et qui représente un flux binaire JPEG 2000. Dans les annexes A,
Figure img00060001

B et C, et dans la suite de la description, les lettres xsd identifient les outils qui sont définis dans XML-schema. Et les lettres bsd identifient les outils qui sont ajoutés par l'invention.
Conformément à l'invention, le schéma B2 (qui est considéré comme étant identique au schéma B'2 dans la suite de la description) définit le type de toutes les données susceptibles d'être contenues dans un flux conforme au format JPEG 2000. Certains types de données sont pré-existants dans le langage XML-schema et peuvent être utilisés directement. D'autres doivent être modifiés. D'autres encore doivent être ajoutés.
En particulier, un flux binaire conforme au format JPEG 2000 contient les types de données suivants : 1) des segments binaires de longueurs indéfinies, dont le contenu peut être importé dans un document XML en utilisant un premier ou un deuxième mode d'importation, décrits plus loin.
2) des mots binaires de différentes longueurs, qui contiennent éventuellement des bits de remplissage qui ne sont pas significatifs.
Figure img00060002
3) des marqueurs dont la valeur est définie en hexadécimales dans la norme JPEG 2000, et qui sont importés en hexadécimales dans le document XML. Cette importation en hexadécimales constitue un troisième mode d'importation.
<Desc/Clms Page number 7>
Le premier mode d'importation consiste à convertir les données binaires en caractères appartenant à l'ensemble prédéfini de caractères utilisé par XML. Pour cela, on utilise avantageusement une méthode de codage connue sous le nom de base 64 et décrite au paragraphe 6.8 du document RFC 2045 publié par LIETF. Cette méthode consiste à découper les données binaires à convertir en groupes de 6 bits, et à associer à chaque groupe de 6 bits un caractère de l'ensemble prédéfini de caractères. Ce premier mode d'importation entraîne une expansion des données de 33%.
Dans le deuxième mode d'importation, au lieu de convertir les données binaires en caractères pour les insérer directement dans le document XML, on introduit dans le document XML des pointeurs vers une zone d'un fichier binaire qui contient lesdites données binaires. Le document XML devient alors dépendant dudit fichier binaire.
Dans le langage XML-schema, un type de données est définit comme un triplet qui comprend : - un ensemble de valeurs, appelé espace de valeurs, - un ensemble de représentations lexicales, appelé espace lexical, - un ensemble de facettes, une facette correspondant à une contrainte imposée à l'espace de valeurs.
Pour la mise en oeuvre de l'invention, le codage des données qui sont lues dans le flux binaire doit être univoque et implicite. Certains types de données pré-existants dans XMLschema, qui sont univoques et implicites, sont utilisés directement : c'est le cas par exemple des types de données xsd : unsignedShort qui représente un entier compris entre-32768 et +32767 et qui peut donc être codé implicitement sur deux octets. C'est également le cas de xsd : unsîgnedint et de xsd : unsignedByte .
Conformément à l'invention, on utilise aussi le type de données xsd : binary , mais en le modifiant : 1) On lui ajoute une facette relative à un drapeau de fin, intitulée bsd : stopFlagExclusive .
Cette facette sera utilisée pour indiquer la fin d'un segment binaire de longueur indéfinie : par exemple les paquets JPEG 2000, qui sont des segments binaires de longueur indéfinie, sont délimités soit par un marqueur SOP (de l'anglais Start Of Paket), soit par un marqueur SOT (de l'anglais Start Of Tile) soit par un marqueur EOC (de l'anglais End Of Codestream) ; donc pour un paquet JPEG 2000 cette facette aura l'une des trois valeurs FF51 (SOP), FF90 (SOT) ou FFD9 (EOC).
2) On ajoute une nouvelle valeur possible à la facette encoding qui existe déjà dans le
Figure img00070001

langage XML-schema avec les valeurs hex pour l'hexadecimal et base 64 pour l'importation après une conversion base 64. La nouvelle valeur ajoutée est dénommée externalData . Elle est utilisée pour indiquer que les données sont importées dans le document XML en utilisant le second mode d'importation évoqué plus haut (introduction dans le document XML d'un pointeur qui pointe vers la zone du flux binaire qui contient les données concernées).
<Desc/Clms Page number 8>
Ce type de données modifié est intitulé binaryNoLength et il est définit à l'annexe C de la façon suivante : < xsd : simpleType name="binaryNoLength" > < xsd : annotation > < xsd : appinfo > < !-- Read data until a flag is found-- > < xsd : hasFacet name="stopFlagExclusive"/ > < !-- How binary data should be instantiated :-- > < !-- base64, hex (same as for xsd : binary)-- > < !-- externalData (URI pointing to an external entity data segment < xsd : hasFacet name="encoding"/ > < /xsd : appinfo > < /xsd : annotation > < xsd : restriction base="xsd : anySimpleType"/ > < /xsd : simpleType > Ce type de données modifié, qui est un type générique, est ensuite utilisé pour dériver d'autres types de données spécifiques susceptibles d'être rencontrés dans un flux binaire XML. Par
Figure img00080001

exemple, comme indiqué à l'annexe B, le type PacketDataTYpe , qui correspond aux paquets JPEG 2000, est dérivé du type générique binaryNoLength . Dans cet exemple, on voit que les données contenues dans ces paquets sont importées dans le document XML en utilisant le second mode d'importation (pointeur vers la zone du flux binaire qui contient les données). On voit aussi qu'un paquet JPEG 2000 est délimité par un marqueur ayant l'une des trois valeurs suivantes : FF51, FFD9, ou FF90.
< xsd : simpleType name="packetDataType" > < xsd : restriction base="bsd : binaryNoLength" > < xsd : encoding value="externalData"/ > < bsd : stopFlagExclusive value="FF51 1 FFD9 1 FF90"/ > < /xsd : restriction < /xsd : simpleType >
Figure img00080002

En se reportant à l'annexe A, on constate que d'autres éléments ont un type dérivé de binaryNoLength , par exemple l'élément intitulé Data dans l'élément de type complexe COC. Cet élément Data a une facette encoding dont la valeur est base 64 , ce qui signifie que les données correspondantes sont importées du flux binaire dans le document XML en utilisant une conversion base 64. < xsd : complexType name="COCType" > < xsd : sequence >
Figure img00080003

< xsd : element name="Marker"type="jp2 : markerType" fixed="ff53"/ > < xsd : element name="Lcoc"type="xsd : unsignedShort"/ > < xsd : element name="data" > < xsd : simpleType > < xsd : restriction base="xsd : binary" > < xsd : length value="$Lcoc"/ > < xsd : encoding value="base64"/ >
<Desc/Clms Page number 9>
< /xsd : restriction > < /xsd : simpleType > < /xsd : éléments < /xsd : sequence > < /xsd : complexType >
L'invention consiste aussi à ajouter un nouveau type de données destiné à être utilisé
Figure img00090001

pour les mots binaires de longueur prédéfinie. Ce nouveau type de données est intitulé bsd : bitsArray et il contient trois facettes : une facette intitulée bitslength relative à la longueur du mot binaire, une facette intitulée prePadding relative au nombre de bits de remplissage placés avant le ou les bits significatifs, et une facette intitulée postPadding relative au nombre de bits de remplissage placés après le ou les bits significatifs. Ce nouveau type de données est défini dans l'annexe C de la façon suivante : < xsd : simpleType name="bitsArray" > < xsd : annotation > < xsd : appinfo < xsd : hasFacet name="bitsLength"/ > < xsd : hasFacet name="prePadding"/ > < xsd : hasFacet name="postPadding"/ > < /xsd : appinfo < /xsd : annotation > < xsd : restriction base="xsd : anySimpleType"/ > < /xsd : simpleType > Comme indiqué à l'annexe B, ce nouveau type de données, qui est un type de données générique, est ensuite utilisé pour dériver des types de données spécifiques susceptibles d'être
Figure img00090002

rencontrés dans un flux JPEG 2000. Par exemple le type de données intitulé llb qui est dérivé du type de données générique bitsArray correspond à un mot binaire de 11 bits, qui ne contient pas de bits de remplissage : < xsd : simpleType name="llb" > < xsd : restriction base="bsd : bitsArray" > < bsd : bitsLength value="11"/ > < /xsd : restriction > < /xsd : simpleType > Et le type de données intitulé 5b3p qui est aussi dérivé du type de données générique bitsarray correspond à un mot binaire de 5 bits qui comporte 2 bits significatifs suivis de 3 bits de remplissage.
Figure img00090003
< xsd : simpleType name="5b3p" > < xsd : restriction base="bsd : bitsArray" > < bsd : bitsLength value="5"/ > < bsd : postPadding value="3"/ > < /xsd : restriction < /xsd : simpleType >
<Desc/Clms Page number 10>
Figure img00100001

En se reportant à l'annexe A on constate que le type de données llb est par exemple utilisé pour l'élément intitulé mantissa : xsd : element name="mantissa"type="jp2 : llb"/ > et que le type de données 5b3p est par exemple utilisé pour l'élément intitulé exponent : < xsd : element name="exponent"type="jp2 : 5b3p"/ > D'un point de vue structurel, l'invention utilise les outils suivants qui existent déjà dans XML-schema : - les types de données simples et complexes xsd : simple Type et xsd : complexType , - les éléments xsd : element , - les modèles de groupe xsd : group , - les connecteurs xsd : sequence , xsd : all , et éventuellement xsd : choice .
L'analyseur syntaxique B3 lit le flux binaire BI avec le schéma B2 pour générer une représentation arborescente B4 du flux binaire Bl. Cette représentation arborescente B4 est une instance du schéma B2. Elle est générée récursivement en interprétant les connecteurs rencontrés dans le schéma.
En particulier, le connecteur xsd : sequence est interprété de la façon suivante par l'analyseur syntaxique : lorsque l'analyseur syntaxique rencontre un connecteur xsd : sequence , il lit les éléments dans le flux binaire dans le même ordre que dans le schéma. Par exemple, un connecteur xsd : sequence est utilisé dans les éléments du type CodestreamType défini dans l'annexe A.
< xsd : complexType name="CodestreamType" > < xsd : sequence > < xsd : element name="MainHeader"type="jp2 : MainHeaderType"/ > < xsd : element name="Tile"type="jp2 : TileType"/ > < xsd : element name="EOC"type="jp2 : EOCType"/ > < /xsd : sequence > < /xsd : complexType > D'après cette définition, un élément Codestream comprend obligatoirement un élément Mainheader , suivi d'un élément Tile , suivi d'un élément EOC .
Le connecteur xsd : all est interprété de la façon suivante par l'analyseur syntaxique : lorsque l'analyseur syntaxique rencontre un connecteur xsd : all , ils commence par essayer de lire le premier élément déclaré à l'intérieur du connecteur xsd : all , et steil échoue, il essaye de lire le second etc... Lorsqu'il trouve un élément recherché, il passe à l'élément suivant dans le connecteur xsd : all . oil ne passe au connecteur suivant que lorsque tous les éléments du connecteur xsd : all ont été parcourus.
<Desc/Clms Page number 11>
Figure img00110001
D'une façon générale, l'élément trouvé dans le flux binaire ne correspond pas à l'élément recherché lorsque le schéma définit une valeur fixe pour cet élément ou pour l'un des éléments qui) contient, et que cette valeur ne correspond pas à ce qui est trouvé dans le flux binaire. Par exemple, lorsque l'analyseur syntaxique essaie d'instancier un élément SIZ , l'élément lu dans le flux binaire n'est pas l'élément recherché s'il ne commence pas par FF51 qui est la valeur affectée au marqueur SIZ dans la norme JPEG 2000.
Le connecteur xsd : all est par exemple utilisé dans les éléments du type MainHeader Type défini dans l'annexe A.
< xsd : complexType name="MainHeaderType" > < xsd : sequence > < xsd : element name="SOC"type="jp2 : SOCType"/ > < xsd : element name="SIZ"type="jp2 : SIZType"/ > < xsd : group > < xsd : all > < xsd : element name="COD"type="jp2 : CODType"minOccurs="0"/ > < xsd : element name="QCD"type="jp2 : QCDType"minOccurs="0"/ > < xsd : element name="COC"type="jp2 : COCType"minOccurs="O"/ > < xsd : element name="QCC"type="jp2 : QCCType"minOccurs="0"/ > < xsd : element name="RGN"type="jp2 : RGNType"minOccurs="0"/ > < xsd élémentname="POC"type=jp2 POCType"min0ccurs="0"/ > < xsd élémentname="PPM"type=jp2 PPMType"min0ccurs="0"/ > < xsd : element name="TLM"type="jp2 : TLMType"minOccurs="O"/ > < xsd : element name="PLM"type="jp2 : PLMType"minOccurs="O"/ > < xsd : element name="CRG"type="jp2 : CRGType"minoccurs="O"/ > < xsd : element name="COM"type="jp2 : COMType"min0cpurs="0"/ > < /xsd : all > < /xsd : group > < /xsd : sequence > < /xsd : complexType > D'après cette définition un élément MainHeader comprend obligatoirement un élément SOC suivi d'un élément SIZ suivi d'un groupe qui peut contenir un, plusieurs ou aucun des éléments suivants, pris dans un ordre quelconque : COD , QCD , COC , QCC , RGN , POC , PPM , TLM , PLM , CRG .
Bien qu'aucun exemple n'en soit donné dans l'annexe A, on peut également utiliser le connecteur xsd : choice . Lorsque l'analyseur syntaxique rencontre un connecteur xsd : choice , il commence par essayer de lire dans le flux binaire le premier élément déclaré à l'intérieur du connecteur xsd : choice . Lorsqu'il trouve l'élément recherché, il passe au connecteur suivant dans le schéma. Lorsque l'élément lu n'est pas l'élément recherché, il passe à l'élément suivant à l'intérieur du même connecteur xsd : choice .
Par ailleurs, l'invention introduit l'utilisation de variables dans les schémas. La notion de variable est utilisée dans le langage XSLT (XMLExtensible StyleSheet Language Transformation en anglais). XSLT est un langage spécifié par le consortium W3C, qui permet de définir des transformation applicables à des documents XML. Concrètement une variable est une chaîne de caractères liée à une valeur. Elle peut apparaître à un certain emplacement dans un document et être utilisée ailleurs. Conformément à la syntaxe définie dans XSLT, on accède à la valeur d'une variable identifiée par une chaîne de caractères en plaçant le signe $ devant la chaîne de
<Desc/Clms Page number 12>
Figure img00120001

caractères (autrement dit, $ZZZ est la valeur de la variable identifiée par la chaîne de caractères ZZZ). La valeur d'une variable est indiquée dans la définition de la variable. L'invention permet de définir la valeur d'une variable sous forme d'un chemin dans une arborescence XML, en utilisant la syntaxe définit dans le langage Xpath (XML Path Language en anglais). Xpath est aussi un langage spécifié par le consortium W3C. Les spécifications de XSLT et Xpath sont disponibles sur le site Internet http : //www. w3. org.
L'utilisation d'une variable permet par exemple de définir un nombre d'éléments par un paramètre, au lieu de le définir par une valeur constante. Lorsque la valeur d'un paramètre est donnée en amont dans le flux binaire, et informe sur la structure ou le contenu de la suite du flux binaire, la valeur de la variable est définie en utilisant la syntaxe Xpath.
Par exemple, dans le format JPEG 2000, le nombre de composantes comp-siz contenues dans le segment de marqueurs SIZ est défini dans un paramètre Csiz qui est
Figure img00120002

placé en amont dans le segment de marqueurs SIZ. Dans l'annexe A l'élément Csiz est défini comme une variable. Sa valeur est définie par un chemin dans la représentation arborescente en cours de construction : à cet égard, l'expression SIZ/Csiz indique que Csiz est un élément fils de l'élément SIZ . Ensuite, lors de la définition du type complexe SIZ il est fait appel à cette variable Csiz pour déterminer le nombre d'occurrences de l'élément comp-siz .
< xsl : variable name="Csiz" > < xsl : value-of select="SIZ/Csiz"/ > < /xsl : variable >
Figure img00120003

< xsd : element name="Comp siz"minOccurs="$Csiz"maxOccurs="$Csiz" > L'invention consiste aussi à ajouter un nouveau modèle de groupe bsd : conditionalChoice et deux nouveaux connecteurs xsl : if et xsl : choose . Cela permet d'introduire des branchements conditionnels dans les schémas et donc d'exprimer des choix conditionnels susceptibles d'exister dans le format que l'on cherche à décrire. On notera que les connecteurs xsl : if et xsl : choose sont définis dans le langage XSLT. Conformément aux spécifications du langage XSLT, les connecteurs xsl : if et xsl : choose utilisent un attribut test qui permet de définir un choix en fonction du résultat d'un test. Le connecteur xsl : if permet de définir un choix en fonction de la valeur d'une variable booléenne. Le connecteur xsl : choose permet de définir un choix parmi une pluralité d'alternatives.
A titre d'exemple, le format JPEG 2000 prévoit que la présence de certains éléments, ou que le type d'une donnée, dépende de la valeur d'un paramètre qui est donné en amont dans le flux binaire.
C'est le cas notamment dans l'élément SPcod qui est contenu dans l'élément
Figure img00120004

COD . L'élément SPcod contient un élément PredinctSize , uniquement lorsque la
<Desc/Clms Page number 13>
Figure img00130001

variable PredinctsUsed a la valeur 1. Cette contrainte est exprimée dans le schéma en utilisant un connecteur xsl : if .
< xsd : element name="SPcod" > < xsd : complexType > < xsd : sequence > < xsd : element name="nDecompLevels"type="xsd : unsignedByte"/ > < xsd : element name="codeBlockNidth"type="jp2 : 4p4b"/ > < xsd : element name="codeBlockHeight"type="jp2 : 4p4b"/ > < xsd : element name="codeBlockStyle" > < xsd : complexType > < xsd : sequence > < xsd : element name="optSegMarkers"type="jp2 : 2plb"/ > < xsd : element name="optErTerm"type="jp2 : lb"/ > < xsd : element name="optVertStrCausal"type="jp2 : lb"/ > < xsd : element name="optRegTerm"type="jp2 : lb"/ > < xsd : element name="optResetMQ"type="jp2 lb"/ > < xsd : element name="optByPass"type="jp2 : lb"/ > < /xsd : sequence > < /xsd : complexType > < /xsd : element > < xsd : element name="Transformation"type="xsd : unsignedByte"/ > < xsl : if test="$PrecinctsUsed=l" > < xsd : element name="PrecinctSize"min0ccurs="0" > < xsd : complexType > < xsd : sequence < xsd : element name="PPy"type="jp2 : 4b"/ > < xsd : element name="PPx"type="jp2 : 4b"/ > < /xsd : sequence > < /xsd : complexType > < /xsd : element > < /xsd : sequence > < /xsl : if > < /xsd : complexType > < /xsd : element > Dans l'élément QCD on trouve un exemple d'un groupe bsd : cond) tiona ! Choice qui utilise des connecteurs xsl : choose pour indiquer que le type d'un élément à suivre (Spqcdl, Spqcd~2 ou Spqcd~3) dépend de la valeur d'un paramètre quantStyle dont l'emplacement, dans la représentation arborescente en cours d'élaboration, est donnée par le chemin QCD/Sqcd/QuantStyle . bsd : conditionalChoice > < xsl : choose > < xsl : when test="QCD/Sqcd/quantStyle ='0"' > < xsd : element name="Spqcdl"minOccurs="3*$nDecompLevels+l" maxOccurs="3*$nDecompLevels+l" > < xsd : complexType > < xsd : sequence > < xsd : element name="exponent"type="jp2 : 5b3p"/ > < /xsd : sequence > < /xsd : complexType > < /xsd : element > < /xsl : when > xsl : when test="QCD/Sqcd/quantStyle =' !'" > < xsd : element name="Spqcd~2"minOccurs="l"maxOccurs="l" > < xsd : complexType > < xsd : sequence >
<Desc/Clms Page number 14>
Figure img00140001

xsd : element name="exponent"type="jp2 : 5b"/ > < xsd : element name="mantissa"type="jp2 : llb"/ > < /xsd : sequence > < /xsd : complexType > < /xsd : element > < /xsl : when >
Figure img00140002

xsl : when test="QCD/Sqcd/quantStyle ='2"' > < xsd : element name="Spqcd~3"minOccurs="3*$nDecompLevels+l" maxOccurs="3*$nDecompLevels+l" > xsd : complexType > < xsd : sequence > < xsd : element name="exponent"type="jp2 : 5b"/ > < xsd : element name="mantissa"type="jp2 : llb"/ > < /xsd : sequence > < /xsd : complexType > < /xsd : element > < /xsl : when > < /xsl : choose > < /bsd : conditionalChoice
Figure img00140003

Lorsqu'il lit le flux binaire, l'analyseur syntaxique génère progressivement un arbre XML.
Lorsque) rencontre une variable dans te schéma, par exemple dans un attribut test d'un connecteur if , il évalue cette variable en appliquant le chemin indiqué.
On notera que le langage XML permet de définir ses propres extensions. Un premier mode de réalisation de l'invention consiste donc à ajouter les nouveaux outils proposés par l'invention comme extensions du langage XML-schema existant. Un autre mode de réalisation de l'invention consiste à redéfinir entièrement un nouveau langage qui reprend des outils de XMLschema et ajoute les nouveaux outils proposés par l'invention.
Sur la figure 3, on a représenté un exemple de système de transmission selon l'invention. Le système de transmission de la figure 3 comporte un serveur SV et une pluralité de clients CT. Le serveur SV et les clients CT sont reliés au réseau Internet WWW. Le serveur SV contient des moyens de mémorisation MEM et des moyens de traitement PROC. Les moyens de mémorisation contiennent notamment un schéma B2, un premier flux binaire Bl, et un programme d'ordinateur PG1 pour la mise en oeuvre d'un procédé d'analyse syntaxique selon l'invention, afin d'obtenir un premier document B4 qui représente le premier flux binaire Bl et qui est une instance du schéma B2. De façon avantageuse, les moyens de mémorisation MEM contiennent aussi un programme d'ordinateur PG2 pour la mise en oeuvre d'un procédé de génération d'un second flux binaire B'l à partir d'un document le représentant B'4, et du schéma B2.
A titre d'exemple, le document B'4 est obtenu en appliquant une transformation au document B4, ladite transformation dépendant du profile d'un client qui a préalablement requit le transfert d'un flux binaire.
<Desc/Clms Page number 15>
Figure img00150001

Annexe A : schema
Figure img00150002

< ? xml version="1. 0" encoding="UTF-8" ? > < !-- Schema of a bitsream compliant to : JPEG 2000 Part I Final Draft International Standard ISO/IEC JTCl/SC29 Wog1, JPEG 2000 - - > < xsd : schema targetNamespace="JP2" xmlns : jp2="JP2" xmlns : xsd="http ://www. w3. org/2000/10/XMLSchema" xmlns : bsd="BSDLPrimitiveTypes" xmlns : xsl="http ://www. w3. org/1999/XSL/Transform" elementFormDefault="qualified" > < xsd : include schemaLocation="JP2SimpleTypes. xsd"/ > < !-- Variables-- > < bsd : variables < xsl : variable name="nDecompLevels" > < xsl : value-of select="COD/SPcod/nDecompLevels"/ > < /xsl : variable > < xsl : variable name="Csiz" > < xsl : value-of select="SIZ/Csiz"/ > < /xsl : variable) < xsl : variable name="PrecinctsUsed" > < xsl : value-of select="COD/Scod/PrecinctsUsed"/ > < /xsl : variables < xsl : variable name="Lcoc" > < xsl : value-of select="COC/Lcoc" > < /xsl : variable > < xsl : variable name="Lqcc" > < xsl : value-of select="QCC/Lqcc" > < /xsl : variable > < xsl : variable name="Lrgn" > < xsl : value-of select="RGN/Lrgn" > < /xsl : variable > < xsl : variable name="Lpoc" > < xsl : value-of select="POC/Lpoc" > < /xsl : variable > < xsl : variable name="Lppm" > < xsl : value-of select="PPM/Lppm" > < /xsl : variable > < xsl : variable name="Ltlm" > < xsl : value-of select="TLM/Ltlm" > < /xsl : variable > < xsl : variable name="Lcrg" > < xsl : value-of select="CRG/Lcrg" > < /xsl : variable > < xsl : variable name="Lcom" > < xsl : value-of select="COM/Lcom" > < /xsl : variable > < xsl : variable name="Lqcd" > < xsl : value-of select="QCD/Lqcd" > < /xsl : variable > < xsl : variable name="Lppt" > < xsl : value-of select="PPT/Lppt" > < /xsl : variable >
<Desc/Clms Page number 16>
Figure img00160001

< xsl : variable name=nLplt" > < xsl : value-of select="PLT/Lplt" > < /xsl : variable > < /bsd : variables < !-- &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num; Codestream Element Declaration &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;-- > < xsd : element name="Codestream"type="jp2 : CodestreamType"/ > < !-- &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num; Codestream complex type < xsd : complexType name="CodestreamType" > < xsd : sequence > < xsd : element name="MainHeader"type="jp2 : MainHeaderType"/ > < xsd : element name="Tile"type="jp2 : TileType"/ > < xsd : element name="EOC"type="jp2 : EOCType"/ > < /xsd : sequence > < /xsd : complexType > e ! -- &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num; MainHeader complex type < xsd : complexType name="MainHeaderType" > < xsd : sequence > < xsd : element name="SOC"type="jp2 : SOCType"/ > < xsd : element name==="SIZ"type="jp2 : SIZType"/ > < xsd : group > < xsd : all > < xsd : element name="COD"type="jp2 : CODType"minOccurs="0"/ > < xsd : element name="QCD"type="jp2 : QCDType"minOccurs="0"/ > < xsd : element name="COC"type="jp2 : COCType"minOccurs="0"/ > < xsd : element name="QCC"type="jp2 : QCCType"minOccurs="0"/ > exsd : element name="RGN" type="jp2 : RGNType" minOccurs="O"/ > < xsd : element name="POC"type="jp2 : POCType"minOccurs="0"/ > < xsd : element name="PPM"type="jp2 : PPMType"minOccurs="0"/ > < xsd : element name="TLM"type="jp2 : TLMType"minOccurs="0"/ > < xsd : element name="PLM"type="jp2 : PLMType"minOccurs="0"/ > < xsd element name="CRG"type="jp2 : CRGType"minOccurs="0"/ > < xsd : element name="COM"type="jp2 : COMType"minOccurs="0"/ > < /xsd : all > < /xsd : group > < /xsd : sequence > < /xsd : complexType > < !-- &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num; Tile complex type &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;-- > < xsd : complexType name="TileType" > < xsd : sequence > < xsd : element name="TileHeader"type="jp2 : TileHeaderType"/ > < xsd : element name="Bitstream"type="jp2 : BitstreamType"/ > < /xsd : sequence > < /xsd : complexType > < !-- &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num; TileHeader complex type &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;-- > < xsd : complexType name="TileHeaderType" > < xsd : sequence > < xsd : element name="SOT"type="jp2 : SOTType"/ > < xsd : group > < xsd : all > < xsd : element name="COD"type="jp2 : CODType"minOccurs="0"/ > < xsd : element name="COC"type="jp2 : COCType"minOccurs="0"/ > < xsd : element name="QCD"type="jp2 : QCDType"minOccurs="0"/ > < xsd : element name="QCC"type="jp2 : QCCType"minOccurs="0"/ > < xsd : element name="RGN"type="jp2 : RGNType"minOccurs="0"/ > < xsd : element name="POC"type="jp2 : POCType"minOccurs="0"/ > < xsd : element name="PPT"type="jp2 : PPTType"minOccurs="0"/ > < xsd : element name="PLT"type="jp2 : PLTType"minOccurs="0"/ > < xsd : element name="COM"type="jp2 : COMType"minOccurs="0"/ > < /xsd : all > < /xsd : group > < xsd : element name="SOD"type="jp2 : SODType"/ > < /xsd : sequence >
<Desc/Clms Page number 17>
Figure img00170001

< /xsd : complexType > < !-- Bitstream complex type < xsd : complexType name="BitstreamType" > < xsd : sequence > < xsd : element name="Packet"max0ccurs="unbounded" > < xsd : complexType > < xsd : sequence > < xsd : element name="SOP"type="jp2 : SOPType"/ > < xsd : element name="Data" > < xsd : simpleType > < xsd : union memberTypes="jp2 : packetDataType"/ > < /xsd : simpleType > < /xsd : element > < /xsd : sequence > < /xsd : complexType < /xsd : element > < /xsd : sequence < /xsd : complexType < 1-- &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num; -- > Marker Segments SOC complex type < 1-- &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num; SOC complex type &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;-- > < xsd : complexType name="SOCType" > < xsd : sequence < xsd : element name="Marker"type="jp2 : markerType" fixed="ff4f"/ > < /xsd : sequence > < /xsd : complexType > < !-- &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num; SIZ complex type < xsd : complexType name="SIZType" > < xsd : sequence > < xsd : element name="Marker"type="jp2 : markerType"fixed="ff51"/ > < xsdélémentname="Lsiz"type="xsd unsignedShort"/ > < xsdélémentname="Rsiz"type="xsd unsignedShort"/ > < xsdélémentname="Xsiz"type="xsd unsignedlnt"/ > < xsdélémentname="Ysiz"type="xsd unsignedlnt"/ > < xsdélémentname="XOsiz"type="xsd unsignedlnt"/ > < xsdélémentname="YOsiz"type="xsd unsignedlnt"/ > < xsd : element name="XTsiz"type="xsd : unsignedInt"/ > < xsdélémentname="YTsiz"type="xsd unsignedlnt"/ > < xsdélémentname="XTOsiz"type="xsd unsignedlnt"/ > < xsdélémentname="YTOsiz"type="xsd unsignedlnt"/ > < xsdélémentname="Csiz"type="xsd unsignedShort"/ > < xsd : element name="Comp~siz"minOccurs="$Csiz"maxOccurs="$Csiz" > < xsd : complexType > < xsd : sequence > < xsd : element name="Ssiz" > < xsd : complexType > < xsd : sequence > < xsd : element name="sign"type="jp2 : lb"/ > < xsd : element name="bitDepth"type="jp2 : 7b"/ > < /xsd : sequence < /xsd : complexType > < /xsd : element > < xsd : element name="XRsiz"type="xsd : unsignedByte"/ > < xsd : element name="YRsiz"type="xsd : unsignedByte"/ > < /xsd : sequence > < /xsd : complexType > < /xsd : element > < /xsd : sequence < /xsd : complexType > < !-- COD complex type < xsd : complexType name="CODType" >
<Desc/Clms Page number 18>
Figure img00180001

< xsd : sequence > < xsd : element name="Marker"type="jp2 : markerType" fixed="ff52"/ > < xsd : element name="Lcod"t : ype="xsd : unsignedShort"/ > < xsd : element name="Scod" > < xsd : complexType > < xsd : sequence > < xsd : element name="EPHMarkersUsed"type="jp2 : Splb"/ > < xsd : element name="SOPMarkersUsed"type="jp2 : lb"/ > < xsd : element name="PrecinctsUsed"type="jp2 : lb"/ > < /xsd : sequence > < /xsd : complexType > < /xsd : element > < xsd : element name="SGcod" > < xsd : complexType > < xsd : sequence > < xsd : element name="progType"type="xsd : unsignedByte"/ > < xsd : element name="numLayers"type="xsd : unsignedShort"/ > < xsd : element name="mct"type="xsd : unsignedByte"/ > < /xsd : sequence > < /xsd : complexType > < /xsd : elements < xsd : element name="SPcod" > < xsd : complexType > < xsd : sequence > < xsd : element name="nDecompLevels"type="xsd : unsignedByte"/ > < xsd : element name="codeBlockWidth"type="jp2 : 4p4b"/ > < xsd : element name="codeBlockHeight"type="jp2 : 4p4b"/ > < xsd : element name="codeBlockStyle" > < xsd : complexType > < xsd : sequence > < xsd : element name="optSegMarkers"tyBe="jp2 : 2plb"/ > < xsd : element name="optErTerm"type="jp2 : lb"/ > < xsd : element name="optVertStrCausal"type="jp2 : lb"/ > < xsdélémentname="optRegTerm"type="jp2 lb"/ > < xsdélémentname="optResetMQ"type="jp2 lb"/ > < xsd : element name="optByPass"type="jp2 : lb"/ > < /xsd : sequence > < /xsd : complexType > < /xsd : element > < xsd : element name="Transformation"type="xsd : unsignedByte"/ > < xsl : if test="$PrecinctsUsed=l" > < xsd : element name="PrecinctSize"min0ccurs="0" > < xsd : complexType > < xsd : sequence > < xsd : element name="PPy"type="jp2 : 4b"/ > < xsd : element name="PPx"type="jp2 : 4b"/ > < /xsd : sequence > < /xsd : complexType > < /xsd : element > < /xsd : sequence > < /xsl : if > < /xsd : complexType > < /xsd : éléments < /xsd : sequence > < /xsd : complexType > < !-- &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num; QCD complex types < xsd : complexType name="QCDType" > < xsd : sequence > < xsd : element name="Marker"type="jp2 : markerType" fixed="ff5c"/ > < xsd : element name="Lqcd"type="xsd : unsignedShort"/ > < xsd : element name="Sqcd" > < xsd : complexType > < xsd : sequence > < xsd : element name="guardBits"type="jp2 : 3b"/ >
<Desc/Clms Page number 19>
Figure img00190001

< xsd : element name="quantStyle"type="jp2 : 5b"/ > < /xsd : sequence > < /xsd : complexType > < /xsd : element > < bsd : conditionalChoice > < xsl : choose > < xsl : when test="QCD/Sqcd/quantStyle ='0"' > < xsd : element name="Spqcdl"minOccurs="3*$nDecompLevels+l" max0ccurs="3 * $nDecompLevels+1" > < xsd : complexType > < xsd : sequence > < xsd : element name="exponent"type="jp2 : 5b3p"/ > < /xsd : sequence > < /xsd : complexType > < /xsd : éléments < /xsl : when > < xsl : when test="QCD/Sqcd/quantStyle =' !'" > < xsd : element name="Spqcd~2"minOccurs="l"max0ccurs="l" > < xsd : complexType > < xsd : sequence > < xsd : element name="exponent"type="jp2 : 5b"/ > < xsd : element name="mantissa"type="jp2 : llb"/ > < /xsd : sequence > < /xsd : complexType < /xsd : element > < /xsl : when > < xsl : when test="QCD/Sqcd/quantStyle ='2"' > < xsd : element name="Spqcd3"minOccurs="3*$nDecompLevels+l" maxOccurs="3*$nDecompLevels+l " > < xsd : complexType > < xsd : sequence > < xsd : element name="exponent"type="jp2 : 5b"/ > < xsd : element name="mantissa"type="jp2 : llb"/ > < /xsd : sequence > < /xsd : complexType > < /xsd : element > < /xsl : when > < /xsl : choose > < /bsd : conditionalChoice > < /xsd : sequence > < /xsd : complexType > < !-- &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num; < t&num;&num;&num;&num; SOT complex type < xsd : complexType name="SOTType" > < xsd : sequence > < xsd : element name="Marker"type="jp2 : markerType"fixed="ff90"/ > < xsd : element name="Lsot"type="xsd : unsignedShort"fixed="10"/ > < xsdélémentname="Isot"type="xsd unsignedshort"/ > < xsd : element name="Psot"type="xsd : unsignedlnt"/ > < xsdélémentname="TPsot"type="xsd unsignedByte"/ > < xsdélémentname="TNsot"type="xsd unsignedByte"/ > < /xsd : sequence > < /xsd : complexType > < !-- SOD complex type &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;-- > < xsd : complexType name="SODType" > < xsd : sequence > < xsd : element name="Marker"type="jp2 : markerType" fixed="ff93"/ > < /xsd : sequence > < /xsd : complexType > < !-- SOP complex types < xsd : complexType name="SOPType" > < xsd : sequence
<Desc/Clms Page number 20>
Figure img00200001

< xsd : element name="Marker"type="jp2 : markerType" fixed="ff91"/ > < xsd : element name="Lsop"type="xsd : unsignedShort" fixed="4"/ > < xsd : element name="Nsop"type="xsd : unsignedShort"/ > < /xsd : sequence > < /xsd : complexType > < ! -- &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num; EOC complex types < xsd : complexType name="EOCType" > < xsd : sequence > < xsd : element name="Marker"type="jp2 : markerType" fixed="ffd9"/ > < /xsd : sequence > < /xsd : complexType > < !--&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;-- > < !-- Non implemented Marker Segments < ! -- &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num; -- > < '--For the following markers, different parameters are not read individually because they are not needed in the application.
Instead, the marker segment content is read as a whole using the length information given after the marker-- > < !-- COC complex types < xsd : complexType name="COCType" > < xsd : sequence > < xsd : element name="Marker"type="jp2 : markerType" fixed="ff53"/ > < xsd : element name="Lcoc"type="xsd : unsignedShort"/ > < xsd : element name="data" > < xsd : simpleType > < xsd : restriction base="xsd : binary" > < xsd : length value="$Lcoc"/ > < xsd : encoding value="base64"/ > < /xsd : restriction < /xsd : simpleType > < /xsd : element > < /xsd : sequence > < /xsd : complexType > < !-- &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num; QCC complex types < xsd : complexType name="QCCType" > < xsd : sequence > < xsd : element name="Marker"type="jp2 : markerType" fixed="ff5d"/ > < xsd : element name="Lqcc"type="xsd : unsignedShort"/ > < xsd : element name="data" > < xsd : simpleType > < xsd : restriction base="xsd : binary" > < xsd : length value="$Lqcc"/ > < xsd : encoding value="base64"/ > < /xsd : restriction > < /xsd : simpleType > < /xsd : element > < /xsd : sequence > < /xsd : complexType > < !-- RGN complex type-- > < xsd : complexType name="RGNType" > < xsd : sequence > < xsd : element name="Marker"type="jp2 : markerType" fixed="ff5e"/ > < xsd : element name="Lrgn"type="xsd : unsignedShort"/ > < xsd : element name="data" > < xsd : simpleType > < xsd : restriction base="xsd : binary" > < xsd : length value="$Lrgn"/ > < xsd : encoding value="base64"/ > < /xsd : restriction > < /xsd : simpleType >
<Desc/Clms Page number 21>
Figure img00210001

< /xsd : element > < /xsd : sequence < /xsd : complexType < i--POC complex type &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;-- > < xsd : complexType name="POCType" > < xsd : sequence > < xsd : element name="Marker"type="jp2 : markerType" fixed="ff5f"/ > < xsd : element name="Lpoc"type="xsd : unsignedShort"/ > < xsd : element name="data" > < xsd : simpleType > < xsd : restriction base="xsd : binary" > < xsd : length value="$Lpoc"/ > < xsd : encoding value="base64"/ > < /xsd : restriction, < /xsd : simpleType > < /xsd : éléments < /xsd : sequence > < /xsd : complexType > < !-- PPM complex type-- > < xsd : complexType name="PPMType" > < xsd : sequence > < xsd : element name="Marker"type="jp2 : markerType" fixed="ff60"/ > < xsd : element name="Lppm"type="xsd : unsignedShort"/ > < xsd : element name="data" > < xsd : simpleType < xsd : restriction base="xsd : binary" > < xsd : length value="$Lppm"/ > < xsd : encoding value="base64"/ > < /xsd : restriction < /xsd : simpleType < /xsd : elements < /xsd : sequence < /xsd : complexType < !-- TLM complex type &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;-- > < xsd : complexType name="TLMType" > < xsd : sequence > < xsd : element name="Marker"type="jp2 : markerType" fixed="ff55"/ > < xsd : element name="Ltlm"type="xsd : unsignedShort"/ > < xsd : element name="data" > < xsd : simpleType > < xsd : restriction base="xsd : binary" > < xsd : length value="$Ltlm"/ > < xsd : encoding value="base64"/ > < /xsd : restriction > < /xsd : simpleType > < /xsd : element > < /xsd : sequence < /xsd : complexType > < !-- PLM complex type &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;-- > < xsd : complexType name="PLMType" > < xsd : sequence > < xsd : element name="Marker"type="jp2 : markerType" fixed="ff57"/ > < xsd : element name="Lplm"type="xsd : unsignedShort"/ > < xsd : element name="data" > < xsd : simpleType > < xsd : restriction base="xsd : binary" > < xsd : length value="$Lplm"/ > < xsd : encoding value="base64"/ > < /xsd : restriction > < /xsd : simpleType
<Desc/Clms Page number 22>
Figure img00220001

< /xsd : element > < /xsd : sequence > < /xsd : complexType > < !-- CRG complex type &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;-- > < xsd : complexType name="CRGType" > < xsd : sequence > < xsd : element name="Marker"type="jp2 : markerType" fixed="ff63"/ > < xsd : element name="Lcrg"type="xsd : unsignedShort"/ > < xsd : element name="data" > < xsd : simpleType > < xsd : restriction base="xsd : binary < xsd : length value="$Lcrg"/ > < xsd : encoding value="base64"/ > < /xsd : restriction > < /xsd : simpleType > < /xsd : element > < /xsd : sequence > < /xsd : complexType > < !-- &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num; COM complex type &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;-- > < xsd : complexType name="COMType" > < xsd : sequence > < xsd : element name="Marker"type="jp2 : markerType" fixed="ff64"/ > < xsd : element name="Lcom"type="xsd : unsignedShort"/ > < xsd : element name="data" > < xsd : simpleType > < xsd : restriction base="xsd : binary" > < xsd : length value="$Lcom"/ > < xsd : encoding value="base64"/ > < /xsd : restriction < /xsd : simpleType > < /xsd : éléments < /xsd : sequence > < /xsd : complexType > < :-- &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num; ppT complex type < xsd : complexType name="PPTType" > < xsd : sequence > < xsd : element name="Marker"type="jp2 : markerType" fixed="ff61"/ > < xsd : element name="Lppt"type="xsd : unsignedShort"/ > < xsd : element name="data" > < xsd : simpleType > < xsd : restriction base="xsd : binary" > < xsd : length value="$Lppt"/ > < xsd : encoding value="base64"/ > < /xsd : restriction > < /xsd : simpleType > < /xsd : element > < /xsd : sequence > < /xsd : complexType > < !-- PLT complex type-- > < xsd : complexType name="PLTType" > < xsd : sequence > < xsd : element name="Marker"type="jp2 : markerType" fixed="ff58"/ > < xsd : element name="Lplt"type="xsd : unsignedShort"/ > < xsd : element name="data" > < xsd : simpleType > < xsd : restriction base="xsd : binary" > < xsd : length value="$Lplt"/ > < xsd : encoding value="base64"/ > < /xsd : restriction > < /xsd : simpleType >
<Desc/Clms Page number 23>
Figure img00230001

< /xsd : element > < /xsd : sequence > < /xsd : complexType > < /xsd : schema >
<Desc/Clms Page number 24>
Figure img00240001

Annexe B : Type simples utilisés dans le schéma
Figure img00240002

< ? xml version="1. O" encoding="UTF-8" ? > < xsd : schema targetNamespace="JP2" xmlns : jp2="JP2" xmlns : xsd="http ://www. w3. org/2000/10/XML5chema" xmlns : bsd="BSDLPrimitiveTypes" elementFormDefault="qualified" > < xsd : import namespace=""schemaLocation="BSDIjPrimitiveTypes. xsd"/ > < 1-- &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num; Simple Types Definition &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num; -- > Simple Types Definition markertype < xsd : simpleType name="markerType" > < xsd : restriction base="xsd : binary" > < xsd : encoding value="hex"/ > < xsd : length value="2"/ > < /xsd : restriction > < /xsd : simpleType > < !-- bitstreamtype < !-- This type used for bitstream packets-- > < !-- They are delimited by either : - a new SOP marker (FF51) - a new SOT marker (FF90) - the EOC marker (FFD9)-- > < xsd : simpleType name="packetDataType" > -- < xsd : restriction base="bsd : binaryNoLength" > < xsd : encoding value="externalData"/ > < bsd : stopFlagExclusive value="FF51 I FFD9 FF90"/ > < /xsd : restriction > < /xsd : simpleType > - < xsd : simpleType name="llb" > < xsd : restriction base="bsd : bitsArray" > < bsd : bitsLength value="ll"/ > < /xsd : restriction < /xsd : simpleType > < xsd : simpleType name="7b" > < xsd : restriction base="bsd : bitsArray" > < bsd : bitsLength value="7"/ > < /xsd : restriction > < /xsd : simpleType > < xsd : simpleType name="5b" > < xsd : restriction base="bsd : bitsArray" > < bsd : bitsLength value="5"/ > < /xsd : restriction > < /xsd : simpleType > < xsd : simpleType name="4b" > < xsd : restriction base="bsd : bitsArray" > < bsd : bitsLength value="4"/ > < /xsd : restriction > < /xsd : simpleType < xsd : simpleType name="3b" > < xsd : restriction base="bsd : bitsArray" > < bsd : bitsLength value="3"/ > < /xsd : restriction > < /xsd : simpleType >
<Desc/Clms Page number 25>
Figure img00250001

< xsd : simpleType name="lb" > < xsd : restriction base="bsd : bitsArray" > < bsd : bitsLength value="l"/ > < /xsd : restriction > < /xsd : simpleType > < xsd : simpleType name="2plb" > < xsd : restriction base="bsd : bitsArray" > < bsd : bitsLength value="l"/ > < bsd : prePadding value="2"/ > < /xsd : restriction > < /xsd : simpleType > < xsd : simpleType name="Splb" > < xsd : restriction base="bsd : bitsArray" > < bsd : bitsLength value="l"/ > < bsd : prePadding value="5"/ > < /xsd : restriction > < /xsd : simpleType > < xsd : simpleType name="5b3p" > < xsd : restriction base="bsd : bitsArray" > < bsd : bitsLength value="5"/ > < bsd : postPadding value="3"/ > < /xsd : restriction > < /xsd : simpleType > < xsd : simpleType name="4p4b" > < xsd : restriction base="bsd : bitsArray" > < bsd : bitsLength value="4"/ > < bsd : prePadding value="4"/ > < /xsd : restriction > < /xsd : simpleType > < /xsd : schema >
<Desc/Clms Page number 26>
Annexe C : Types génériques utilisés dans le schéma
Figure img00260001

< ? xml version="1. O" encoding="UTF-8" ? > < xsd : schema targetNamespace="BSDLPrimitiveTypes" xmlns : bsd="BSDLPrimitiveTypes" xmlns : xsd="http ://www. w3. org/2000/10/XMLSchema" elementFormDefault="qualified" > < !-- bitsArray < xsd : simpleType name="bitsArray" > < xsd : annotation > < xsd : appinfo > < xsd : hasFacet name="bitsLength"/ > < xsd : hasFacet name="prePadding"/ > < xsd : hasFacet name="postPadding"/ > < /xsd : appinfo > < /xsd : annotation > < xsd : restriction base="xsd : anySimpleType"/ > < /xsd : simpleType > < !-- &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num; binaryNoLength &num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;&num;-- > < xsd : simpleType name="binaryNoLength" > < xsd : annotation > < xsd : appinfo > < 1-- Read data until a flag is found-- > < xsd : hasFacet name="stopFlagExclusive"/ > < I--How binary data should be instantiated :-- > < I--base64, hex (same as for xsd : binary)-- > < i--externalData (URI pointing to an external entity data segment)-- > < xsd : hasFacet name="encoding"/ > < /xsd : appinfo > < /xsd : annotation > < xsd : restriction base="xsd : anySimpleType"/ > < /xsd : simpleType > < /xsd : schema >
<Desc/Clms Page number 27>
Figure img00270001

Annexe D : Document instance du schéma
Figure img00270002

< ? xml version="1. O" ? > < !-- example of an XML representation of a JP2 bitstream-- > < Codestream xmlns="JP2" xmlns : xsi="http : //www. w3. org/2000/10/XMLSchema-instance" xsi : schemaLocation="JP2 JP2. xsd" > < MainHeader > < SOC > < Marker > FF4F < /Marker >
Figure img00270003

< /SOC > < SIZ > < Marker > ff51 < /Marker > < LSiz > 47 < /Lsiz > < Rsiz > O < /Rsiz > < Xsiz > 515 < /Xsiz > < Ysiz > 512 < /Ysiz > < XOsiz > 0 < /XOsiz > < YOsiz > 0 < /YOsiz > < XTsiz > 515 < /XTsiz > < YTsiz > 512 < /YTsiz > < XTOsiz > 0 < /XTOsiz > < YTOsiz > 0 < /YTOsiz > < Csiz > 3 < /Csiz > < Comp~siz > < Ssiz > < sign > O < /sign > < bitDepth > 7 < /bitDepth > < /Ssiz > < XRsiz > l < /XRsiz > < YRsiz > l < /YRsiz > < /Comp~siz > < Compsiz > < Ssiz > < sign > 0 < /sign > < bitDepth > 7 < /bitDepth > < /Ssiz > < XRsiz > l < /XRsiz > < YRsiz > l < /YRsiz >
Figure img00270004

< /Compsiz > < Comp~siz > < Ssiz > < sign > O < /sign > < bitDepth > 7 < /bitDepth > < /Ssiz > < XRsiz > l < /XRsiz > < YRsiz > l < /YRsiz > < /Comp~siz > < /SIZ > < COD > < Marker > ff52 < /Marker > < Lcod > 12 < /Lcod > < Scod > < EPHMarkersUsed > 0 < /EPHMarkersused > < SOPMarkersUsed > 0 < /SOPMarkersused > < PrecinctsUsed > O < /PrecinctsUsed > < /Scod > < SGcod > < progType > 4 < /progType > < numLayers > 1 < /numLayers > < mct > l < /mct >
<Desc/Clms Page number 28>
< /SGcod > < SPcod > < nDecompLevels > 5 < /nDecompLevels > < codeBlockWidth > 4 < /codeBlockWidth > < codeBlockHeight > 4 < /codeBlockHeight > < codeBlockStyle > < optSegMarkers > 0 < /optSegMarkers > < optErTerm > 0 < optErTerm > < optVertStrCausal > O < /optVertStrCausal > < optRegTerm > 0 < /optRegTerm > < optResetMQ > 0 < /optResetMQ > < optByPass > 0 < /optByPass > < /codeBlockStyle > < Transformation > 0 < /Transformation > < /SPcod > < /COD > < QCD > < Marker > ff5c < /Marker > < Lqcd > 35 < /Lqcd > < Sqcd > < guardBits > 2 < /guardBits > < quantStyle > 2 < quantStyle > < /Sqcd > < Spqcd~3 > < exponent > 13 < /exponent > < mantissa > 1816 < /mantissa > < /Spqcd3 >
Figure img00280001

< Spqcd-3 > < exponent > 13 < /exponent > < mantissa > 1770 < /mantissa > < /Spqcd3 > < Spqcd~3 > < exponent > 13 < /exponent > < mantissa > 1770 < /mantissa > < /Spqcd3 > < Spqcd3 > < exponent > 13 < /exponent > < mantissa > 1724 < /mantissa > < /Spqcd3 > < Spqcd3 > < exponent > 12 < /exponent > < mantissa > 1792 < /mantissa > < /Spqcd3 > < Spqcd3 > < exponent > 12 < /exponent > < mantissa > 1792 < /mantissa > < /Spqcd3 > < Spqcd3 > < exponent > 12 < /exponent > < mantissa > 1762 < /mantissa > < /Spqcd3 > < Spqcd3 > < exponent > ll < /exponent > < mantissa > 1868 < /mantissa > < /Spqcd3 > < Spqcd3 > < exponent > ll < /exponent > < mantissa > 1868 < /mantissa > < /Spqcd3 > < Spqcd3 > < exponent > 11 < /exponent > < mantissa > 1892 < /mantissa > < /Spqcd~3 > < Spqcd~3 > < exponent > 9 < /exponent > < mantissa > 3 < /mantissa > < /Spqcd~3 > < Spqcd~3 >
<Desc/Clms Page number 29>
< exponent > 9 < /exponent > < mantissa > 3 < /mantissa > < /Spqcd3 > < Spqcd3 > < exponent > 9 < /exponent > < mantissa > 69 < /mantissa > < /Spqcd3 > < Spqcd~3 > < exponent > 9 < /exponent > < mantissa > 2002 < /mantissa > < /Spqcd3 > < Spqcd3 > < exponent > 9 < /exponent > < mantissa > 2002 < /mantissa > < /Spqcd~3 > < Spqcd3 > < exponent > 9 < /exponent > < mantissa > 1889 < /mantissa > < /Spqcd3 > < /QCD > < /MainHeader > < Tile > < TileHeader > < SOT > < Marker > ff90 < /Marker > < Lsot > 10 < /Lsot > < Isot > O < /Isot > < Psot > 32722 < /Psot > < TPsot > 0 < /TPsot > < TNsot > l < /TNsot > < /SOT >
Figure img00290001

< SOD > < Marker > FF93 < /Marker > < /SOD > < /TileHeader > < Bitstream > < Packet >
Figure img00290002

< SOP > < Marker > ff91 < /Marker > < Lsop > 4 < /Lsop > < Nsop > O < /Nsop >
Figure img00290003

< /SOP > < Data > bachComp3. jp2&num;122-363 < /Data > < /Packet > < Packet > < SOP > < Marker > ff91 < /Marker > < Lsop > 4 < /Lsop > < Nsop > l < /Nsop > < /SOP > < Data > bachComp3. jp2&num;370-861 < /Data > < /Packet > < Packet > < SOP > < Marker > ff91 < /Marker > < Lsop > 4 < /Lsop > < Nsop > 2 < /Nsop >
Figure img00290004

< /SOP > < Data > bachComp3. jp2&num;868-2362 < /Data > < /Packet > < Packet > < SOP > < Marker > ff91 < /Marker > < Lsop > 4 < /Lsop > < Nsop > 3 < /Nsop > < /SOP > < Data > bachComp3. jp2&num;2369-6788 < /Data > < /Packet >
<Desc/Clms Page number 30>
< Packet > < SOP > < Marker > ff91 < /Marker > < Lsop > 4 < /Lsop > < Nsop > 4 < /Nsop > < /SOP > < Data > bachComp3. jp2&num;6795-17999 < /Data > < /Packet > < Packet > < SOP > < Marker > ff91 < /Marker > < Lsop > 4 < /Lsop > < Nsop > 5 < /Nsop > < /SOP > < Data > bachComp3.jp2&num;18006-26441 < /Data > < /Packet > < Packet > < SOP > < Marker > ff91 < /Marker > < Lsop > 4 < /Lsop > < Nsop > 6 < /Nsop >
Figure img00300001

< /SOP > < Data > bachComp3. jp2&num;26448-26577 < /Data > < /Packet > < Packet > < SOP > < Marker > ff91 < /Marker > < Lsop > 4 < /Lsop > < Nsop > 7 < /Nsop >
Figure img00300002

< /SOP > < Data > bachComp3. jp2&num;26584-26875 < /Data > < /Packet > < Packet > < SOP > < Marker > ff91 < /Marker > < Lsop > 4 < /Lsop > < Nsop > 8 < /Nsop > < /SOP > < Data > bachComp3. jp2&num;26882-27675 < /Data > < /Packet > < Packet > < SOP > < Marker > ff91 < /Marker > < Lsop > 4 < /Lsop > < Nsop > 9 < /Nsop > < /SOP > < Data > bachComp3. jp2&num;27682-29664 < /Data > < /Packet >
Figure img00300003

< Packet > < SOP > < Marker > ff91 < /Marker > < Lsop > 4 < /Lsop > < Nsop > 10 < /Nsop >
Figure img00300004

< /SOP > < Data > bachComp3. jp2&num;29671-31086 < /Data > < /Packet > < Packet > < SOP > < Marker > ff91 < Marker > < Lsop > 4 < /Lsop > < Nsop > ll < /Nsop >
Figure img00300005

< /SOP > < Data > bachComp3. jp2&num;31093-31389 < /Data > < /Packet > < Packet > < SOP > < Marker > ff91 < /Marker > < Lsop > 4 < /Lsop >
<Desc/Clms Page number 31>
Figure img00310001

< Nsop > 12 < /Nsop > < /SOP > < Data > bachComp3.jp2&num;31396-31498 < /Data > < /Packet >
Figure img00310002

< Packet > < SOP > < Marker > ff91 < /Marker > < Lsop > 4 < /Lsop > < Nsop > 13 < /Nsop >
Figure img00310003

< /SOP > < Data > bachComp3. jp2&num;31505-31688 < /Data > < /Packet > < Packet > < SOP > < Marker > ff91 < /Marker > < Lsop > 4 < /Lsop > < Nsop > 14 < /Nsop >
Figure img00310004

< /SOP > < Data > bachComp3. jp2&num;31695-31956 < /Data > < /Packet > < Packet > < SOP > < Marker > ff91 < /Marker > < Lsop > 4 < /Lsop > < Nsop > 15 < /Nsop >
Figure img00310005

< /SOP > < Data > bachComp3. jp2&num;31963-32497 < /Data > < /Packet > < Packet > < SOP > < Marker > ff91 < /Marker > < Lsop > 4 < /Lsop > < Nsop > 16 < /Nsop >
Figure img00310006

< /SOP > < Data > bachComp3. jp2&num;32504-32816 < /Data > < /Packet > < Packet > < SOP > < Marker > ff91 < /Marker > < Lsop > 4 < /Lsop > < Nsop > 17 < /Nsop > < /SOP >
Figure img00310007

< Data > bachComp3. jp2&num;32823-32823 < /Data > < /Packet > < /Bitstream > < /Tile > < EOC > < Marker > FFD9 < /Marker > < /EOC > < /Codestream >

Claims (4)

  1. Figure img00320001
    bit (s) de remplissage, une facette relative aux dits bits de remplissage, - lorsque ledit format utilise des segments binaires de longueur indéfinie ayant un contenu destiné à être importé dans ladite représentation en utilisant un certain mode d'importation, un type de données correspondant aux dits segments binaires, ayant au moins une facette relative audit mode d'importation et, lorsque lesdits segments binaires sont délimités par un drapeau de fin, une facette relative audit drapeau de fin, b) comporte une pluralité d'éléments pour lesquels il décrit un nom, un type de données, une imbrication, un ordre et un nombre d'occurrence (s) prédéfinis ou quelconques, l'occurrence d'un élément étant obligatoire ou optionnelle, c) lorsque ledit format prévoit que des données situées en amont dans ledit flux binaire informent sur la structure ou le contenu de la suite dudit flux binaire, - définit une ou plusieurs variable (s) constituée (s) par un chemin d'accès aux dites données situées en amont, dans ladite représentation arborescente, - et comporte un ou plusieurs branchement (s) conditionnel (s) pour décrire les différentes structures ou contenus possibles en fonction de la valeur de la ou desdites variables, B) rechercher dans ledit flux binaire les données qui correspondent aux éléments contenus dans ledit schéma, C) générer une instance dudit schéma qui contient les données trouvées dans ledit flux binaire, et qui constitue ladite représentation arborescente.
    Figure img00320002
    REVENDICATIONS 1. Procédé d'analyse syntaxique d'un flux binaire contenant des données qui ont une structure et un contenu conforme à un certain format, pour générer une représentation arborescente dudit flux, caractérisé en ce que ledit procédé consiste à : A) lire un schéma qui, pour décrire ledit format de façon générique : a) définit un ou plusieurs type (s) de données, susceptible (s) de contenir une ou plusieurs acette (s), dont notamment : - lorsque ledit format utilise des mots binaires de longueur (s) prédéfinie (s), un ou plusieurs types de données correspondant aux dits mots binaires de longueur (s) prédéfinie (s), ayant au moins une facette relative à ladite longueur et, lorsque lesdits mots binaires de longueur (s) prédéfinie (s) sont susceptibles de contenir un ou plusieurs
  2. 2. Programme d'ordinateur comportant des instructions pour la mise en oeuvre d'un procédé d'analyse syntaxique selon la revendication 1.
    <Desc/Clms Page number 33>
  3. 3. Procédé de génération d'un flux binaire conforme à un certain format, à partir d'un document qui est une représentation arborescente dudit flux binaire et qui contient des données, notamment des données importées en utilisant un certain mode d'importation, caractérisé en ce qu'il consiste à : A) lire ledit document, B) lire en parallèle un schéma qui, pour décrire ledit format le façon générique : a) définit un ou plusieurs type (s) de données susceptible (s) d'avoir une ou plusieurs facette (s), notamment : - un type de données correspondant à des segments binaires de longueur indéfinie ayant au moins une facette relative audit mode d'importation, - et, lorsque ledit format utilise des mots binaires de longueur (s) prédéfinie (s), un ou plusieurs types de données correspondant aux dits mots binaires de longueur (s) prédéfinie (s) ayant au moins une facette relative à ladite longueur, et lorsque lesdits mots binaires contiennent un ou plusieurs bit (s) de remplissage, une facette relative aux dits bits de remplissage, b) comporte une pluralité d'éléments pour lesquels il décrit un nom, un type de données, une imbrication, un ordre et un nombre d'occurrence (s) prédéfinis ou quelconques, l'occurrence d'un élément étant obligatoire ou optionnelle, c) lorsque ledit format prévoit que des données situées en amont dans ledit flux binaire informent sur la structure ou le contenu de la suite dudit flux binaire : - définit une ou plusieurs variable (s) constituée (s) par un chemin d'accès aux dites données situées en amont, dans ladite représentation arborescente, - et comporte un ou plusieurs branchement (s) conditionnel (s) pour décrire les différentes structures ou contenus possibles en fonction de la valeur de la ou desdites variables, pour déterminer le type des données contenues dans ledit document, C) coder lesdites données en fonction du type déterminé à l'étape B, D) à constituer un flux binaire à partir des données codées à l'étape C.
  4. 4. Programme d'ordinateur comportant des instructions pour la mise en oeuvre d'un procédé de génération d'un flux binaire selon la revendication 3.
FR0102764A 2001-02-28 2001-02-28 Schema, procede d'analyse syntaxique et procede de generation d'un flux binaire a partir d'un schema Withdrawn FR2821458A1 (fr)

Priority Applications (12)

Application Number Priority Date Filing Date Title
FR0102764A FR2821458A1 (fr) 2001-02-28 2001-02-28 Schema, procede d'analyse syntaxique et procede de generation d'un flux binaire a partir d'un schema
BR0204315-7A BR0204315A (pt) 2001-02-28 2002-02-08 Processo para analisar sintaticamente uma corrente de bits, programa de computador, processo para gerar uma corrente de bits, esquema definindo um ou mais tipos de dados que podem possuir uma ou mais facetas, unidade de processamento, e, sistema de transmissão
KR1020027014532A KR100898614B1 (ko) 2001-02-28 2002-02-08 스키마, 구문 분석 방법 및 스키마에 기초하여 비트 스트림을 발생시키는 방법
RU2003128962/09A RU2294012C2 (ru) 2001-02-28 2002-02-08 Структура данных и способы преобразования потока битов в электронный документ и формирования потока битов из электронного документа на ее основе
PCT/IB2002/000393 WO2002069187A1 (fr) 2001-02-28 2002-02-08 Schema, procede d'analyse syntactique et procede de production de train de bits sur la base d'un schema
EP02710247A EP1366439A1 (fr) 2001-02-28 2002-02-08 Schema, procede d'analyse syntactique et procede de production de train de bits sur la base d'un schema
US10/258,924 US7080318B2 (en) 2001-02-28 2002-02-08 Schema, syntactic analysis method and method of generating a bit stream based on a schema
MXPA02010534A MXPA02010534A (es) 2001-02-28 2002-02-08 Esquema, metodo de analisis sintactico y metodo para generar una corriente de bit basada en un esquema.
JP2002568241A JP4260481B2 (ja) 2001-02-28 2002-02-08 スキーマ、構文解析方法及びスキーマに基づいてビットストリームを発生する方法
CNB028014421A CN100449530C (zh) 2001-02-28 2002-02-08 大纲、语法分析方法和基于一种大纲生成一个位流的方法
PL02363513A PL363513A1 (en) 2001-02-28 2002-02-08 Schema, syntactic analysis method and method of generating a bit stream based on a schema
TW091103306A TW563036B (en) 2001-02-28 2002-02-25 Schema, syntactic analysis method and method of generating a bit stream based on a schema

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0102764A FR2821458A1 (fr) 2001-02-28 2001-02-28 Schema, procede d'analyse syntaxique et procede de generation d'un flux binaire a partir d'un schema

Publications (1)

Publication Number Publication Date
FR2821458A1 true FR2821458A1 (fr) 2002-08-30

Family

ID=8860580

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0102764A Withdrawn FR2821458A1 (fr) 2001-02-28 2001-02-28 Schema, procede d'analyse syntaxique et procede de generation d'un flux binaire a partir d'un schema

Country Status (11)

Country Link
EP (1) EP1366439A1 (fr)
JP (1) JP4260481B2 (fr)
KR (1) KR100898614B1 (fr)
CN (1) CN100449530C (fr)
BR (1) BR0204315A (fr)
FR (1) FR2821458A1 (fr)
MX (1) MXPA02010534A (fr)
PL (1) PL363513A1 (fr)
RU (1) RU2294012C2 (fr)
TW (1) TW563036B (fr)
WO (1) WO2002069187A1 (fr)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4040577B2 (ja) 2001-11-26 2008-01-30 コーニンクリク・フィリップス・エレクトロニクス・ナムローゼ・フエンノートシャップ スキーマ、構文解析法、およびスキーマに基づいてビットストリームを発生させる方法
ATE513415T1 (de) * 2001-12-28 2011-07-15 Koninkl Philips Electronics Nv Verfahren zur verarbeitung von multimediainhalt
JP2006520033A (ja) * 2003-02-19 2006-08-31 コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ ビットストリームについてのフォーマットを一般的に記述するスキーマに基づいてビットストリームを出力する方法。
EP2242273A1 (fr) * 2009-04-14 2010-10-20 Fraunhofer-Gesellschaft zur Förderung der angewandten Forschung e.V. Schéma de transmission pour informations textuelles
CN104598635B (zh) * 2015-02-06 2018-01-19 无锡江南计算技术研究所 一种基于xml描述的复杂文档自动生成方法
CN107092656B (zh) * 2017-03-23 2019-12-03 中国科学院计算技术研究所 一种树状结构数据处理方法及***
RU2762398C2 (ru) * 2019-12-03 2021-12-21 Владимир Дмитриевич Мазур Способ передачи двоичных данных в стандартном звуковом медиапотоке

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR100406806B1 (ko) * 1998-06-24 2003-11-21 시게이트 테크놀로지 엘엘씨 짧게 인터리브된 제한 조건을 갖는 효과적인 런 길이 제한코드
WO2000038329A1 (fr) * 1998-12-21 2000-06-29 Koninklijke Philips Electronics N.V. Dispositif de codage de mots source de n bits en mots de canal correspondants de m bits et de decodage inverse

Non-Patent Citations (7)

* Cited by examiner, † Cited by third party
Title
DUCHARME B: "Setting and Using Variables and Parameters", INTERNET ARTICLE, 7 February 2001 (2001-02-07), XP002183449, Retrieved from the Internet <URL:http://www.xml.com/pub/a/2001/02/07/trxml9.html> [retrieved on 20011120] *
GIRARDOT M ET AL: "Millau: an encoding format for efficient representation and exchange of XML over the Web", COMPUTER NETWORKS, ELSEVIER SCIENCE PUBLISHERS B.V., AMSTERDAM, NL, vol. 33, no. 1-6, June 2000 (2000-06-01), pages 747 - 765, XP004304805, ISSN: 1389-1286 *
LEE D ET AL: "Comparative Analysis of Six XML Schema Languages", ACM SIGMOD RECORD, vol. 29, no. 3, September 2000 (2000-09-01), pages 76 - 87, ISSN: 0163-5808 *
LEE D ET AL: "Comparative Analysis of Six XML Schema Languages", INTERNET ARTICLE, XP002183403, Retrieved from the Internet <URL:http://citeseer.nj.nec.com/lee00comparative.html> [retrieved on 20011120] *
LIEFKE H ET AL: "XMill: an efficient compressor for XML data", PROCEEDINGS OF ACM SIGMOD. INTERNATIONAL CONFERENCE ON MANAGEMENT OF DATA, DALLAS, TX, US, vol. 29, no. 2, 16 May 2000 (2000-05-16) - 18 May 2000 (2000-05-18), pages 153 - 164, XP002168802 *
WILLIAMS R: "XSIL: Java/XML for Scientific Data", INTERNET ARTICLE, June 2000 (2000-06-01), XP002183405, Retrieved from the Internet <URL:http://www.cacr.caltech.edu/SDA/xsil/> [retrieved on 20011120] *
WONG R K ET AL: "An XML repository for molecular sequence data", PROCEEDINGS IEEE INTERNATIONAL SYMPOSIUM ON BIO-INFORMATICS AND BIOMEDICAL ENGINEERING, ARLINGTON, VA, US, 8 November 2000 (2000-11-08) - 10 November 2000 (2000-11-10), IEEE Computer Soc., Los Alamitos, CA, US, pages 35 - 42, XP002183404, ISBN: 0-7695-0862-6 *

Also Published As

Publication number Publication date
KR20020092459A (ko) 2002-12-11
CN1462400A (zh) 2003-12-17
WO2002069187A1 (fr) 2002-09-06
KR100898614B1 (ko) 2009-05-21
BR0204315A (pt) 2003-02-18
PL363513A1 (en) 2004-11-29
CN100449530C (zh) 2009-01-07
RU2003128962A (ru) 2005-03-10
MXPA02010534A (es) 2003-09-22
TW563036B (en) 2003-11-21
EP1366439A1 (fr) 2003-12-03
JP4260481B2 (ja) 2009-04-30
JP2004519771A (ja) 2004-07-02
RU2294012C2 (ru) 2007-02-20

Similar Documents

Publication Publication Date Title
US7080318B2 (en) Schema, syntactic analysis method and method of generating a bit stream based on a schema
JP4197320B2 (ja) 構造化された文章、特にxml文章の符号化/復号化のための方法及び装置
EP1316220B1 (fr) Procede de compression/decompression de documents structures
US20070271274A1 (en) Using a community generated web site for metadata
KR100750962B1 (ko) 구조적 데이터 구문 분석
WO2002063776A2 (fr) Procede de compression/decompression d&#39;un document structure
FR2926378A1 (fr) Procede et dispositif de traitement pour l&#39;encodage d&#39;un document de donnees hierarchisees
US8892991B2 (en) Encoder compiler, computer readable medium, and communication device
EP1358583B1 (fr) Procede de codage et de decodage d&#39;un chemin dans l&#39;arborescence d&#39;un document structure
FR2929778A1 (fr) Procedes et dispositifs de codage et de decodage binaire iteratif pour documents de type xml.
CN1750640A (zh) TV-Anytime元数据服务中的利用了get-Data操作的请求域提供方法
FR2821458A1 (fr) Schema, procede d&#39;analyse syntaxique et procede de generation d&#39;un flux binaire a partir d&#39;un schema
US20100023470A1 (en) Knowledge based encoding of data
Van Deursen et al. NinSuna: a fully integrated platform for format-independent multimedia content adaptation and delivery using Semantic Web technologies
US20050235009A1 (en) Type evolution
EP1343327B1 (fr) Procédé pour effectuer un traitement sur un contenu multimedia
EP1999649B1 (fr) Procede de generation d&#39;un fichier de description d&#39;un flux binaire, dispositif et produit programme d&#39;ordinateur correspondants
KR100494845B1 (ko) 확장성 생성 언어 기반의 메타데이터 부호화 장치 및 그방법
FR2852177A1 (fr) Procede de proposition d&#39;un service fourni par un ordinateur serveur dans un reseau de communication
FR2911200A1 (fr) Procede et dispositif de traitement de documents a partir de schemas enrichis et procede et dispositif de decodage correspondants
KR20050023411A (ko) 구조화된 문서들, 특히 xml 문서들을인코딩/디코딩하기 위한 방법 및 장치
FR2820528A1 (fr) Procede de transfert d&#39;objet avec adaptation de format
KR100910061B1 (ko) 디지털 방송을 위한 메타데이터 부호화/복호화 장치 및 그방법
Marco et al. Extracting metadata from JPEG2000 compressed images using Web services
Avaro¹ et al. Systems Architecture

Legal Events

Date Code Title Description
ST Notification of lapse