WIPOSTAD (v3.0)

Liens associés

Rechercher WIPOSTAD

Raccourcis

Actions

Langue: English | Español | Français

Norme ST.86

Version 1.0

RECOMMANDATION RELATIVE À L’UTILISATION DU XML (EXTENSIBLE MARKUP LANGUAGE) DANS LE TRAITEMENT DE L’INFORMATION EN MATIÈRE DE DESSINS ET MODÈLES INDUSTRIELS
Norme adoptée par le Groupe de travail du SCIT sur les normes et la documentation lors de sa neuvième session le 21 février 2008

TABLE DES MATIÈRES


  • Appendix A
    • ST.86 XML Dictionary | version: 1.0 | html
  • Appendix B - ST.86 XML Schemas
    • XML Model Schema | version: 1.0 | xsd
    • XML Schemas for External Referenced Standards:
      • ISOCountryCodeType-V2006 | version: 1.0 | xsd
      • ISOCurrencyCodeType-V2001 | version: 1.0 | xsd
      • ISOLanguageCodeType-V2002 | version: 1.0 | xsd
      • WIPOST3CodeType-V2007 | version: 1.0 | xsd
  • Appendix C - ST.86 Associated Class Diagrams
    • Dependencies | version: 1.0 | pdf
    • Transaction-Payment-Design | version: 1.0 | pdf
    • Applicant-Representative-Address Book | version: 1.0 | pdf
    • Opposition | version: 1.0 | pdf
    • Design Record | version: 1.0 | pdf
    • Payment | version: 1.0 | pdf
  • Appendix D - List of Acronyms and Abbreviations | version: 1.0 | visualiser | pdf
    • ST.36 XML Schema Fragments | version: 1.0 | xsd
    • Sample Schema | version: 1.0 | xsd
    • Sample data | version: 1.0 | xml

Introduction

1.

La présente norme recommande l’utilisation de ressources XML (eXtensible Markup Language) pour le dépôt, le traitement, la publication et l’échange de tout type d’information en matière de dessins et modèles industriels. Elle s’inspire largement des normes ST.66 et ST.36 de l’OMPI.

2.

Le terme “ressources XML” désigne l’un quelconque des éléments servant à créer et faire fonctionner une application XML. Pour de plus amples informations sur le Consortium W3C (World Wide Web Consortium), voir http://www.w3c.org/.

3.

Le terme “schéma XML” désigne un langage servant à décrire la structure et limiter le contenu de documents XML.

4.

Il existe de nombreux langages de schéma fondés sur le langage XML. La présente norme ne recommande que le langage schéma XML du Consortium W3C. Le terme “définition du schéma XML (XSD)” est un exemple de schéma XML écrit dans le langage de schéma XML du Consortium W3C. Une XSD définit une catégorie de documents XML en ce qui concerne les limites applicables aux éléments et aux attributs qui peuvent figurer, leur relation mutuelle, les types de données qu’ils peuvent comprendre, etc.

5.

Le langage XML ne peut pas être utilisé en tant que tel comme base pour le traitement des documents relatifs aux dessins et modèles industriels. Par conséquent, la présente norme définit les éléments et leurs identificateurs génériques, ou “balises”, et les attributs pour le balisage des documents relatifs aux dessins et modèles industriels. C’est‑à‑dire qu’elle indique, dans une certaine mesure, la sémantique (signification), l’utilisation et les noms des types, éléments et attributs qui constituent les différents types de documents visés.

6.

La présente norme a pour but de fournir des structures logiques, indépendantes de tout système, pour le traitement des documents relatifs aux dessins et modèles industriels, qu’il s’agisse de texte ou de données images. Elle tient compte des normes ISO en ce qui concerne le code de pays (ISO3166), le code de langue (ISO639), le code de monnaie (ISO4217) et les codes de la norme ST.3 de l’OMPI en tant que schémas externes.

Définitions et terminologie

7.

Les mots clés DOIT, DOIVENT, NE DOIT PAS, NE DOIVENT PAS, DEVRA, DEVRONT, DEVRAIT, DEVRAIENT, NE DEVRAIT PAS, NE DEVRAIENT PAS, PEUT, PEUVENT, et FACULTATIF(S) utilisés dans ce document doivent être interprétés comme indiqué dans l’appel à observations (RFC 2119) de l’Internet Engineering Task Force (IETF). Lorsque ces mots ne figurent pas en majuscules, ils doivent être pris dans leur sens courant en français.

a) Exemple – le texte d’une définition ou d’une règle. Les exemples ont un caractère indicatif.

b) [Note] – information explicative. Les notes ont un caractère indicatif.

8.

Aux fins de la présente recommandation,

a) on entend par “dessins et modèles industriels” les caractéristiques bidimensionnelles ou tridimensionnelles de la forme ou de la surface des objets, qui correspondent respectivement aux notions de dessin et de modèle lorsqu’une distinction est faite entre l’un et l’autre; le terme “dessins ou modèles industriels” n’englobe pas les brevets de dessin ou modèle, qui relèvent de la norme ST.9 de l’OMPI;

b) on entend par “documents de dessin ou modèle “ les documents officiels relatifs à des enregistrements ou à des dépôts de dessin ou modèle industriel ainsi que les demandes publiées à cet effet;

c) on entend par “certificat de dessin ou modèle” le document officiel qui est délivré au propriétaire d’un dessin ou modèle industriel certifiant que son dessin ou modèle a été enregistré ou renouvelé, c’est‑à‑dire qu’il a été inscrit au registre des dessins et modèles du pays ou de l’organisation en question, ou que son enregistrement a été renouvelé (cette définition couvre aussi les “certificats” ou les “extraits du registre” délivrés par l’office, par exemple aux fins d’une action en justice);

d) on entend par “gazette” une publication officielle contenant des avis relatifs aux dessins et modèles industriels établis conformément aux prescriptions des législations nationales ou régionales relatives à la propriété industrielle ou aux conventions ou traités internationaux relatifs à la propriété industrielle;

e) on entend par “avis dans une gazette” une annonce complète – y compris les données bibliographiques – qui est publiée dans un bulletin officiel et concerne un enregistrement d’un dessin ou modèle industriel, ou une demande ou un dépôt effectués à cet effet;

f) le sigle “INID” signifie “Identification numérique internationalement agréée en matière de données (bibliographiques)”.

9.

Le balisage est défini comme étant du texte ajouté au contenu d’un document, qui en décrit la structure et d’autres attributs d’une manière indépendante de tout système et de tout traitement dont ce document PEUT faire l’objet.

10.

Pour d’autres définitions, consulter la spécification XML à l’adresse :
http://www.w3c.org/TR/2004/REC-xml11-20040204/.

Portée de la norme

11.

La présente norme vise à donner des indications aux autorités nationales, régionales et internationales qui, à partir des législations nationales ou des conventions internationales relatives à la propriété industrielle, publient des avis, soit sur les demandes d’enregistrement de dessins et modèles industriels soit sur les enregistrements de dessins et modèles industriels.

12.

La présente norme concerne l’utilisation de ressources XML pour l’échange et le traitement des documents relatifs aux dessins et modèles industriels et aux enregistrements relatifs aux opérations portant sur des dessins et modèles industriels. Voir l’appendice 2 pour des schémas types concernant différents types de documents relatifs aux dessins et modèles industriels et d’enregistrements d’opérations.

13.

La présente norme ne porte que sur le schéma XML du Consortium W3C. Bien qu’une DTDXML puisse être créée automatiquement à partir d’un schéma XML conforme à la présente norme, par définition, aucune DTD ne peut être conforme à la présente norme. Voir à l’adresse http://www.w3.org/XML/Schema#dev pour la spécification du schéma XML.

Références

14.

Les normes et les documents ci‑après présentent un intérêt en ce qui concerne la présente norme :

a) Norme ST.3 de l’OMPI : Norme recommandée concernant les codes à deux lettres pour la représentation des États, autres entités et organisations intergouvernementales;

b) Norme ST.36 de l’OMPI : Recommandation relative à l’utilisation du XML dans le traitement de l’information en matière de brevets;

c) Norme ST.66 de l’OMPI : Recommandation relative à l’utilisation du XML dans le traitement de l’information en matière de marques;

d) Norme ST.80 de l’OMPI : Recommandation concernant les données bibliographiques relatives aux dessins et modèles industriels;

e) Norme ST.81 de l’OMPI : Recommandation concernant le contenu et la présentation des bulletins officiels de dessins et modèles industriels

f) Classification internationale pour les dessins et modèles industriels établie en vertu de l’Arrangement de Locarno;

g) ISO/IEC 11179-5 Technologies de l’information – Registres de métadonnées (RM) – Partie 5 : Principes de dénomination et d’identification;

h) ISO 3166‑1 – Codes pour la représentation des noms de pays et de leurs subdivisions – Codes pays;

i) ISO 639‑1 – Codes pour la représentation des noms de langue – Partie 1 : Code Alpha2;

j) ISO 4217 – Codes pour la représentation des monnaies et des types de fonds;

k) ISO 8601 – Éléments de données et formats d’échange – Échange d’information – Représentation de la date et de l’heure;

l) ISO/IEC 10646 – Technologies de l’information – Jeu universel de caractères codés sur plusieurs octets (JUC);

m) La norme ebXML (Electronic Business using XML) proposée par le CEFACT ONU (Centre des Nations Unies pour la facilitation du commerce et des transactions électroniques) et l’OASIS (Organization for the Advancement of Structured Information Standards) est un ensemble modulaire de spécifications pour les transactions électroniques sur l’Internet.1

n) CEFACT ONU – Règles de nommage et de conception pour XML, version 2.0;

o) Règles de nommage et de conception UBL d’OASIS;

p) Invitation à observations (RFC 2119) de l’Internet Engineering Task Force (IETF).

Prescriptions de la norme

15.

Le dictionnaire XML ST.86 figurant dans l’appendice A constitue le fondement de la présente norme.

16.

Le dictionnaire DOIT être utilisé tel qu’il figure dans la présente norme, c’est‑à‑dire que les types, éléments, attributs et énumérations DOIVENT être utilisés tels qu’ils sont indiqués dans la liste du dictionnaire. Toutefois, des énumérations sont définies comme ouvertes et peuvent être limitées ou étendues dans le cadre de la procédure propre aux offices.

17.

Une procédure conforme à la présente norme DOIT être mise en œuvre en application des principes directeurs énoncés dans la présente norme ou DOIT être une extension d’une XSD conforme selon les principes directeurs énoncés dans la présente norme.

18.

Les documents XML conformes à la présente norme DOIVENT être bien formés et validés par la XSD figurant dans l’appendice B.

19.

Il est entendu que la présente norme ne peut pas englober tous les éléments exigés par tous les offices des dessins et modèles industriels; dans ce schéma de mise en œuvre, des éléments propres aux offices sont autorisés de la façon indiquée ci‑dessous dans la partie “Nommage des types et éléments propres aux offices”.

20.

Le langage XSD (définition de schéma XML) adopté par le Consortium W3C est devenu le langage de schéma généralement accepté, c’est‑à‑dire celui dont l’adoption se généralise. Bien qu’il existe d’autres langages de schéma présentant des avantages et des inconvénients propres, toutes les règles de conception de schémas XML DOIVENT être fondées sur les recommandations relatives aux schémas XML du Consortium W3C : Schémas XML, première partie : structures et schémas XML, deuxième partie : type de données. Tous les schémas et messages DOIVENT être fondés sur la série de spécifications techniques du Consortium W3C ayant valeur de recommandation.

21.

Une redéfinition des types de données intégrés de la XSD DEVRAIT être évitée.

22.

La norme ST.3 de l’OMPI DOIT être utilisée pour un pays de dépôt de la demande établissant la priorité, une partie contractante, un office récepteur et un office désigné.

23.

La norme ISO 3166 DOIT être utilisée pour les codes de pays utilisés pour la correspondance, les codes des pays d’exposition et la nationalité.

24.

La norme ISO/IEC 10646 – UCS – UTF‑8 de la norme Unicode DOIT être utilisée pour le jeu de caractères.

25.

La norme ISO 639‑1 (Codes de langue à deux lettres) DOIT être utilisée pour les codes des langues.

26.

La norme ISO 8601 relative à la représentation normalisée de la date et de l’heure au niveau international – DOIT être utilisée pour la représentation de la date et de l’heure. Les types de données du schéma du Consortium W3C comprennent la date et l’heure et DEVRAIENT être utilisés de préférence à la norme ISO 8601, en cas de conflit.

27.

La norme ISO 4217‑Alpha (codes pour la représentation des monnaies à trois lettres) DOIT être utilisée pour les codes des monnaies.

Caractères

28.

La présente norme recommande d’utiliser exclusivement Unicode, même si le langage XML permet d’autres codages des caractères. Il peut être utile d’ajouter des entités de caractères pour les caractères qui ne figurent pas encore dans Unicode. L’utilisation de ces entités nécessite, pour la présentation, la création de glyphes qui n’existent pas encore. Voir http://www.w3.org/XML/Core/2002/10/charents-20021023 pour plus d’informations sur les entités de caractères.

29.

Les documents DOIVENT inclure une déclaration XML à la première ligne du fichier.

<?xml version='1.0' encoding='utf-8' ?>

Noter que seul UTF‑8 est recommandé dans cette norme. Toutefois, en ce qui concerne les scripts idéographiques, la norme Unicode en UTF 8 PEUT produire des fichiers exceptionnellement volumineux étant donné que le codage PEUT nécessiter jusqu’à quatre octets par caractère. Dans ce cas, les offices nationaux PEUVENT choisir un mode de codage qui ramène les fichiers à une taille raisonnable. Les offices qui optent pour cette solution DEVRAIENT être prêts à consulter leurs partenaires avec lesquels ils échangent des données et à avertir le public de façon appropriée.

30.

Les caractères qui peuvent figurer dans un document XML sont précisés dans la recommandation XML 1.0 du Consortium W3C et sont repris dans la présente norme avec l’exception ci‑après. Les caractères utilisés dans des noms de caractères, d’éléments ou d’attributs décrits dans la présente norme se limitent à la série suivante : {a-z, A-Z, 0-9, point (.), tiret (‑) et trait de soulignement (_)}.

Notions générales concernant le langage XML

Contraintes relatives au nommage et à la modélisation

Contraintes relatives au nommage

31.

Chaque entrée du dictionnaire DOIT définir un seul chemin totalement qualifié pour un élément ou un attribut.

Contraintes relatives au nommage

32.

Les bibliothèques et les schémas DOIVENT utiliser uniquement des types de données approuvés.

33.

Aucun contenu mixte NE DOIT être utilisé dans un schéma centré sur les données sauf lorsqu’il est situé dans un élément xsd : documentation.

Réutilisabilité

34.

Toutes les déclarations de type DOIVENT être globales.

Espaces de nommage

Déclaration d’espaces de nommage

35.

Chaque module du schéma, à l’exception des modules de schéma internes, DOIT faire l’objet d’une déclaration d’espace de nommage au moyen de l’attribut xsd:targetNamespace.

36.

Tous les schémas XML DOIVENT indiquer l’espace de nommage du schéma du Consortium W3C. Les schémas DOIVENT indiquer un espace de nommage cible.

37.

La qualification d’espaces de nommage DOIT être utilisée pour structurer le schéma du Consortium W3C.

38.

Toute version du schéma définie ou utilisée DOIT comporter son propre espace de nommage caractéristique.

39.

Les espaces de nommage publiés NE DOIVENT jamais être modifiés.

40.

Il NE DOIT PAS y avoir d’espace de nommage implicite. C’est‑à‑dire, par exemple, que le schéma XML et l’espace de nommage ciblé DOIVENT être explicitement qualifiés. Cette approche, même si elle est assez encombrée, est plus cohérente pour tous les types de schéma ne possédant pas d’espace de nom cible ou en possédant un ou plusieurs. Exemple :

<?xml version="1.0"?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"

targetNamespace="http://www.wipo.int/standards/XMLSchema"

xmlns:lib="http://www.wipo.int/standards/XMLSchema"

elementFormDefault="qualified">

<xsd:include schemalocation="xxx.xsd"/>

</xsd:schema>

41.

Pour cacher ou révéler les espaces de nom dans les documents, l’attribut de passage binaire DEVRAIT être utilisé : elementFormDefault de l’élément <xsd:schema> (qualifié ou non qualifié).

42.

Les renvois à des schémas externes DEVRAIENT utiliser le concept d’inclusion. Les schémas incluant et inclus DOIVENT avoir le même espace de nom cible.

43.

Par souci de simplicité, la préférence DEVRAIT être donnée à une configuration unique d’espace de nom. Des espaces de nom multiples PEUVENT être utilisés à des fins d’extension (nationalisation).

Conventions de nommage

Règles de nommage de balises XML

44.

Les conventions de nommage de balises XML reposent sur les principes définis dans la cinquième partie de la norme ISO 11179. Les noms d’éléments, d’attributs et de types DEVRAIENT consister en la classe objet, le nom du terme de propriété et le nom d’un terme de représentation.

a) Une classe objet identifie le concept fondamental de l’élément. Elle désigne une activité ou un objet dans un contexte opérationnel et PEUT consister en un, deux ou trois mots.

b) Le terme de propriété détermine les caractéristiques de la classe objet. Le nom d’un terme de propriété DOIT apparaître naturellement dans la définition de la balise et PEUT consister en un, deux ou trois mots. Le nom d’un terme de propriété DOIT être unique dans le contexte d’une classe objet mais PEUT être réutilisé dans différentes classes objets.

c) Si le terme de représentation utilise le même mot que le dernier utilisé par le terme de propriété, le terme de représentation DOIT être omis.

d) La classe objet et les termes de représentation DEVRAIENT être omis lorsque le terme de propriété seul est utilisé couramment et suffit à exprimer le concept sans risque de confusion dans son contexte.

e) Par exemple (classe objet + terme de propriété + Terme de représentation) :

  • ApplicantNationalityCode: Applicant(Object Class) + Nationality(Property Term) + Code(Representation Term)

  • ViewFilename: View(Object Class) + Filename(Property Term) + Text(Representation Term, omitted)

  • FilingDate: Mark(Object Class, omitted) + FilingDate(Property Term)+ Date(Representation Term, omitted)

45.

Les noms d’éléments, d’attributs et de types DOIVENT être uniques. Les noms DEVRAIENT être concis et NE DEVRAIENT PAS contenir des mots consécutifs superflus, et DOIVENT être autant que possible suffisamment clairs et très structurés.

46.

Les noms d’éléments, d’attributs et de types et tous leurs éléments DOIVENT être utilisés au singulier sauf si le concept est lui‑même au pluriel.

47.

Les noms d’éléments, d’attributs et de types ne DOIVENT contenir que des noms, des adjectifs et éventuellement des verbes. Les mots tels que “and”, “of”, “the” DOIVENT être supprimés, sauf si leur suppression risque d’induire en erreur. Par exemple, IndicationProduct, OpenToLicencingIndicator.

48.

Les noms d’éléments, d’attributs et de types NE DOIVENT pas être traduits, modifiés ou remplacés dans quelque but que ce soit.

49.

Les noms d’éléments, d’attributs et de types DOIVENT être composés de mots anglais, écrits selon l’orthographe anglaise figurant dans le dictionnaire Oxford English Dictionary, y compris les balises propres à un office (voir le paragraphe 57 pour les exceptions en ce qui concerne les sigles).

50.

Les noms d’éléments DOIVENT figurer en caractères haut de casse de type “camel” (UCC). Le style UCC met en majuscule le premier caractère de chaque mot qui compose le nom. Par exemple, AddressCountryCode.

51.

Les noms de type DOIVENT se présenter sous la forme UCC + type suffixe. Par exemple, LanguageCodeType.

52.

Les noms d’attribut DOIVENT figurer en caractères bas de casse de type “camel” (LCC). Le style LCC met en majuscules le premier caractère de chaque mot à l’exception du premier mot. Par exemple, currencyCode="EUR".

53.

En ce qui concerne l’énumération de valeurs ou les listes de codets, le texte DEVRAIT être court mais suffisant d’un point de vue sémantique et en anglais lorsqu’il n’existe pas de liste de codes normalisés. Les valeurs et les codes DEVRAIENT être tirés du langage utilisé couramment dans les activités relatives à la propriété industrielle.

54.

Une limite de 35 caractères est recommandée pour un nom. Lorsque le même mot est répété dans un nom d’élément, il DEVRAIT être supprimé après sa première occurrence.

55.

Les noms d’éléments, d’attributs et de types NE DOIVENT PAS comprendre de points (.), d’espaces ou d’autres séparateurs, ou de caractères non autorisés par la norme XML 1.0 du Consortium W3C pour les noms XML sauf indications figurant dans la présente norme. Par exemple, préfixe d’office ou de domaine (XX_UCC, XX étant le code indiqué dans la norme ST.3).

56.

Les caractères utilisés dans les noms de valeur de l’énumération indiqués dans la présente norme se limitent aux caractères suivants : {a-z, A-Z, 0-9, point (.), virgule (,), espaces, tiret (‑) et caractère de soulignement (_)}.

Sigles et abréviations

57.

Les noms d’éléments, d’attributs et de types XML NE DOIVENT PAS contenir de sigles, d’abréviations ou d’autres troncatures de mots, à l’exception des indications figurant dans la présente norme ou de la liste de l’appendice D.

58.

Les sigles et les abréviations indiqués dans l’appendice D DOIVENT toujours être utilisés en lieu et place du nom développé complet.

59.

Les sigles et les abréviations au début d’une déclaration d’attribut DOIVENT figurer en caractères de bas de casse. Tous les autres sigles et abréviations utilisés dans une déclaration d’attribut DOIVENT figurer en caractères de haut de casse.

60.

Les sigles DOIVENT figurer en caractères de haut de casse pour toutes les déclarations d’élément et les définitions de type.

Règles de nommage des fichiers de schéma XML

61.

Ces conventions garantiront que les objets seront stockés d’une façon assurant la cohérence, l’uniformité et l’exhaustivité nécessaires, et vaudront pour tous les aspects du stockage et de la réutilisation.

62.

Il est recommandé que les noms de fichier pour les schémas et les feuilles de style soient régis par une règle de nommage en six parties. Cette règle de nommage en six parties est présentée ci‑dessous :

Partie Description Syntaxe
[Office] Utilisation en cas de produits propres à un office ou d’union de codes de plusieurs offices. AA (code de la norme ST.3). Doit être omis pour une version générique d’un office. En ce qui concerne les organisations non mentionnées dans la norme ST.3 de l’OMPI ou les sociétés, elles ne DEVRAIENT pas utiliser des codes à deux lettres mais des codes composés de trois ou quatre UCC.
- Délimiteur. Un seul tiret.
[Domaine] Indication du domaine.

Aaa (nom de longueur variable, longueur maximale de huit caractères).

Exemple :
RCD = dessin ou modèle communautaire enregistré

- Délimiteur. Un seul tiret.
Nom du message ou du service

Nom du message ou du service en UCC

Exemple :
RCDDownloadClassTerm

- Délimiteur. Un seul tiret.
Version

Il existe deux options :

1. Version et sous version (séparée de la partie précédente par un tiret).

2. Version par date (p. ex. ccyy-mm-dd).

. Délimiteur. Un seul point.
Extension Extension de fichier (séparée de la partie précédente par un point).

Aaa (deux à quatre caractères).

Exemple : xsd, xml, xsl

Exemple : EM-RCD-Keyin-V1-0.xsd

[Office] [Domaine] Service de message Version Extension
EM- RCD eFiling V1-1 .xsd
RCDDownload 2007-02-25 .xml

Note : le champ entre crochets [ ] est FACULTATIF.

63.

Les noms de fichier DEVRAIENT suivre les règles de nommage des balises susmentionnées. Toutefois, un mappage peut être défini localement si les règles ne peuvent pas être appliquées en raison de contraintes techniques. Ces règles locales DOIVENT être bien définies et publiées pour tous les utilisateurs potentiels.

64.

Les versions des noms de fichier d’un schéma DEVRAIENT être modifiées lorsqu’un schéma modulaire inclus est mis à jour. En ce qui concerne la dernière version du schéma XML, les offices PEUVENT proposer deux types de la dernière version sur leur site Web : un schéma adapté qui porte un numéro de version appropriée (par exemple, WIPOST3Code V2005‑05‑21.xsd, st36for66 V1 0.xsd) et un schéma non adapté sans numéro de version (par exemple, WIPOST3Code.xsd, st36for66.xsd), qui est une copie de la dernière version du schéma XML (ou qui y renvoie). D’autres offices peuvent faire état de la dernière version en indiquant soit le schéma adapté assorti du numéro de la dernière version soit le schéma non adapté qui est une copie de la dernière version pour éviter de modifier les codes utilisés de l’office chaque fois que le schéma est mis à jour.

Diverses règles XSD

65.

Aucune restriction relative à la longueur d’un champ ne DOIT être définie pour le schéma XML dans le cadre de la norme ST.86, mais PEUT l’être pour les schémas de mise en œuvre.

66.

L’élément <any> DEVRAIT être utilisé pour offrir une extension et conserver le schéma XML de la norme ST.86 (appendice B) ouvert à des éléments supplémentaires. Il DOIT ne pas être utilisé dans les schémas de mise en œuvre.

67.

Les éléments DEVRAIENT être déclarés avec des indicateurs d’occurrence. Les indicateurs d’occurrence ne devraient pas être déclarés explicitement lorsque la valeur requise est la valeur implicite. Par exemple :

<xs:element name="RegistrationNumber" type="xs:string" minOccurs="0"/>

<xs:element name="DesignRepresentationSheet" type="RepresentationSheetType" maxOccurs="unbounded"/>

68.

Le contenu ou la valeur contenue dans les balises et les attributs peut figurer dans n’importe quelle langue, à l’exception des énumérations.

69.

Un historique de la révision du schéma ne DEVRAIT pas figurer dans le schéma proprement dit. La référence à l’historique de la révision ainsi que le numéro de la dernière version et la date du schéma ne DEVRAIENT figurer que dans le schéma XML. L’historique de la révision DEVRAIT mentionner les modifications et en indiquer la date et les détails, dans l’ordre chronologique inverse et telles qu’elles ont été publiées par le biais du site Internet de l’office. Par exemple :

<xs:annotation>

<xs:documentation>NORME ST.86 DE L’OMPI Model Schema Version 1.0, published in 2008-03-02. The revision history is available on WIPO website at http://www.wipo.int/standards/XMLSchema/designs/revision-history-st86model-schema.doc </xs:documentation>

</xs:annotation>

70.

Le prologue DEVRAIT contenir des liens permettant d’accéder à des sources d’information. Par exemple :

<!-- Auteur : SDWG ST.86 Task Force -->

<!-- Contact : xml.standards@wipo.int -->

Nommage de types et d’éléments propres à un office

71.

Un espace de nom DEVRAIT être établi pour les éléments propres à un office, lorsque le code de l’office (norme ST.3) devient le préfixe servant à identifier les éléments qui sont dans cet espace de nom. Par exemple :

xmlns:kr=" http://www.kipo.go.kr"

<kr:element name="Bibliographic">

< kr:complexType mixed="true">

 

<kr:element ref="DocumentCode"/>

<kr:element ref="DocumentName" minOccurs="0"/>

<kr:element ref="ReceiveOffice" minOccurs="0"/>

<kr:element ref="ApplicationDate" minOccurs="0"/>

</kr:complexType>

</kr:element>

72.

Les types qui ne sont pas définis dans la norme peuvent être définis comme propres à un office. Les noms de type DEVRAIENT avoir un préfixe propre à l’organisation suivi d’un seul tiret. Dans le cas des offices de dessins ou modèles industriels, les types DEVRAIENT avoir pour préfixe un code d’office à deux lettres conforme à la norme ST.3 de l’OMPI.

73.

Les organisations ou les offices qui ne sont pas mentionnés dans la norme ST.3 ou les sociétés ne DEVRAIENT pas utiliser de codes à deux lettres mais des codes composés de trois ou quatre lettres en majuscules.

74.

Sinon, un espace de nom unique DEVRAIT être créé pour les éléments propres à un office, lorsque le code de pays ou le symbole de la société devient le préfixe servant à l’identification d’éléments qui figurent dans cet espace de nom.

Entités externes

75.

Une entité externe est un objet qui accompagne un document XML et qui est appelé dans le document. Les entités externes font partie intégrante d’un document relatif à dessin ou modèle industriel. Sans elles, le document XML ne peut pas être analysé, présenté ou compris de façon satisfaisante.

76.

Dans le domaine des dessins et modèles industriels, une entité externe est le plus fréquemment une image, généralement du dessin ou modèle industriel. Les entités externes qui sont des images des dessins et modèles industriels DEVRONT être conformes à l’un ou l‘autre des profils ci‑après publiés par l’OMPI sur son site Web.2

  • JPEG
  • PNG
  • TIFF
  • GIF

77.

Les images peuvent être intégrées dans un document XML sous la forme d’images binaires incrustées codées dans un contenu de type base64Binary qui constitue le type de données standard du schéma W3C XML ainsi que de renvois à des fichiers d’images extérieures, c’est‑à‑dire des entités extérieures. Toutefois, les images DEVRAIENT figurer comme des entités extérieures.

[Fin de la norme]


1  La norme ebXML publiée en 1999 est une initiative du Centre des Nations Unies pour la facilitation du commerce et des transactions électroniques (CEFACT ONU) et de l’Organization for the Advancement of Structured Information Standards (OASIS).

2  Actuellement, l’Équipe d’experts chargée des normes relatives aux marques du SDWG est en train de préparer, pour adoption en tant que norme de l’OMPI, une recommandation concernant le traitement électronique des éléments figuratifs des marques. Cette recommandation peut également être applicable aux dessins et modèles industriels.