WIPOSTAD (v3.0)

Related Links

Search WIPOSTAD

Shortcuts

Actions

Language: English | Español | Français

Norma ST.86

Versión 1.0

RECOMENDACIÓN SOBRE EL TRATAMIENTO EN LENGUAJE EXTENSIBLE DE MARCADO (XML) DE INFORMACIÓN RELATIVA A LOS DISEÑOS INDUSTRIALES
Norma adoptada por el Grupo de Trabajo del SCIT sobre Normas y Documentación en su novena reunión el 21 de febrero de 2008

ÍNDICE


  • 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 | view | pdf
    • ST.36 XML Schema Fragments | version: 1.0 | xsd
    • Sample Schema | version: 1.0 | xsd
    • Sample data | version: 1.0 | xml

Introducción

1.

En la presente Norma se recomienda la utilización de los recursos que ofrece el lenguaje extensible de marcado (XML) para la presentación, el tratamiento, la publicación y el intercambio de todo tipo de información relativa a los diseños industriales. La Norma se basa en gran parte en las Normas ST.66 y ST.36 de la OMPI.

2.

Con la expresión “recursos XML” se hace referencia a cualquiera de los elementos utilizados para crear y operar una aplicación en ese lenguaje. Para más información acerca del W3C (Consorcio World Wide Web), véase http://www.w3c.org/.

3.

Con el término “esquema XML” se describe la estructura y se limita el contenido de los documentos en XML.

4.

Existen numerosos lenguajes de esquema XML. En la presente Norma se recomienda únicamente el lenguaje de esquema XML del W3C. El término “definición de esquema XML (XSD)” corresponde a un esquema XML escrito en un lenguaje de esquema XML del W3C. El XSD define un tipo de documentos XML en relación con las limitaciones en materia de elementos y atributos, su relación entre ellos, qué tipos de datos pueden contener, etcétera.

5.

El XML no puede ser utilizado de por sí como base para la tramitación de documentos relativos a los diseños industriales. Por lo tanto, en la presente norma se definen los elementos y sus identificadores o “etiquetas” genéricas, así como los atributos que se utilizarán para marcar los documentos de diseños industriales, es decir, que la Norma indica en cierta medida la semántica (significado), el uso y los nombres de los elementos y los atributos que componen los diferentes tipos de documentos de que se trate.

6.

La presente Norma tiene por fin proporcionar estructuras lógicas independientes de todo sistema para el tratamiento de textos o datos de imágenes de los documentos de diseños industriales. En la presente Norma se hace referencia a las normas ISO aplicables al código de país (ISO3166), el código de idioma (ISO639), el código de divisa (ISO4217) y el código de la Norma ST.3 de la OMPI en calidad de esquemas externos.

Definiciones y terminología

7.

Las palabras clave DEBE, NO DEBE, DEBERÁ, DEBERÍA, NO DEBERÍA, PUEDE y OPCIONAL serán interpretadas en el presente documento en la manera descrita en el documento RFC (Request For Comments) 2119 del Grupo de Tareas sobre Ingeniería de Internet (IETF). Cuando estas palabras aparezcan en letra minúscula se utilizarán en el sentido habitual del idioma español.

a) Ejemplo – Una representación de una definición o una norma. Los ejemplos son informativos.

b) [Nota] – Información explicativa. Las notas son informativas.

8.

A los fines de la presente recomendación:

a) se entenderá que el término “diseño industrial” engloba las características bidimensionales y tridimensionales de la forma y superficie de un artículo, y por lo tanto, abarca tanto los conceptos de “dibujos” y de “modelos” cuando existan diferencias entre el primero y el segundo; en el término “diseños industriales” no quedan englobadas las patentes de diseño, a las que se aplica la Norma ST.9 de la OMPI;

b) se entenderá por “documentos sobre diseños industriales”, documentos publicados relativos a registros o depósitos de diseños industriales, y solicitudes publicadas a ese respecto;

c) se entenderá por “certificado de diseño”, el documento oficial que se entrega al titular del registro de un diseño certificando que su diseño ha sido registrado o renovado, a saber, que ha sido inscrito en el Registro de diseños del país u organización de que se trate, o que ha sido renovado (esa definición también abarca los términos “certificados” o “extractos del Registro” entregados por la oficina de propiedad industrial, por ejemplo, a los fines de procedimientos judiciales);

d) se entenderá por “boletín oficial”, una publicación oficial que contenga anuncios relativos a los diseños industriales y que esté elaborada de acuerdo con los requisitos de la legislación nacional o regional de propiedad industrial o de los convenios o tratados internacionales sobre propiedad industrial;

e) se entenderá por “inscripción en un boletín oficial”, un anuncio detallado, acompañado de datos bibliográficos, efectuada en un boletín oficial respecto de un registro, depósito o solicitud de registro de diseño industrial;

f) “INID” es la sigla en inglés de “Internationally agreed Numbers for the Identification of (bibliographic) Data”, a saber, números internacionalmente aceptados para la identificación de datos (bibliográficos).

9.

Se entenderá por marcado, el texto que se añada al contenido de un documento y que describa su estructura y otros atributos al margen de cualquier sistema e independientemente de todo tratamiento de que PUEDA ser objeto el documento.

10.

Para otras definiciones, véase la especificación relativa al XML en el sitio http://www.w3c.org/TR/2004/REC-xml11-20040204/.

Alcance de la norma

11.

La presente Norma tiene por fin proporcionar orientación a las autoridades nacionales, regionales e internacionales que, sobre la base de la legislación nacional de propiedad industrial o de los convenios internacionales en materia de propiedad industrial, publiquen anuncios de solicitudes de registro de diseños industriales o de registros de diseños industriales.

12.

La presente Norma tiene por fin proporcionar recursos XML para el intercambio y tramitación de documentos de diseños industriales y registros de transacciones de diseños industriales. Véase el Apéndice 2 para los modelos de esquemas relativos a varios tipos de documentos de diseños industriales y registros de transacción.

13.

La presente Norma abarca únicamente el esquema XML del W3C. Aunque puede generarse automáticamente una DTD de XML a partir de un esquema XML que se halle en concordancia con la presente Norma, por definición, ninguna DTD puede estar en concordancia con la presente Norma. Véase http://www.w3.org/XML/Schema#dev para la especificación del esquema XML.

Material de referencia

14.

Son pertinentes para la presente Norma los siguientes documentos y Normas:

a) Norma ST.3 de la OMPI: Códigos normalizados de dos letras, recomendados para la representación de Estados, otras entidades y organizaciones intergubernamentales;

b) Norma ST.36 de la OMPI: Recomendación sobre el tratamiento en lenguaje extensible de marcado (XML) de la información sobre patentes;

c) Norma ST.66 de la OMPI: Recomendación sobre el tratamiento en lenguaje extensible de marcado (XML) de información relativa a las marcas;

d) Norma ST.80 de la OMPI: Recomendación relativa a los datos bibliográficos sobre dibujos y modelos industriales;

e) Norma ST.81 de la OMPI: Recomendación relativa al contenido y presentación de los boletines de los dibujos y modelos industriales;

f) Clasificación de los diseños industriales en virtud del Arreglo de Locarno;

g) Norma ISO/IEC 11179‑5 Information technology – Metadata registries (MDR) – Part 5: Naming and identification principles;

h) Norma ISO 3166‑1 – Codes for the representation of names of countries and their subdivisions – Country Codes;

i) Norma ISO 639‑1 – Codes for the representation of names of languages – Part 1: Alpha2-code;

j) Norma ISO 4217 – Codes for the representation of currencies and funds

k) Norma ISO 8601 – Data elements and interchange formats – Information interchange – Representation of dates and times;

m) ebXML (transacciones electrónicas en XML), sistema patrocinado por el UN/CEFACT (Centro de las Naciones Unidas para la Facilitación del Comercio y las Transacciones Electrónicas) y la OASIS (Organization for the Advancement of Structured Information Standards): es un conjunto modular de especificaciones para el comercio electrónico en Internet.1

n) UN/CEFACT- Normas de denominación y diseño en XML, Versión 2.0; Standards), versión 2.0;

o) Normas de denominación y diseño de UBL de la OASIS;

p) Grupo de Tareas sobre Ingeniería de Internet (IETF), RFC (Request For Comments) 2119.

Requisitos de la norma

15.

La presente Norma se basa en el Diccionario de XML de la Norma ST.86 que figura en el Apéndice A.

16.

El Diccionario DEBE ser utilizado conforme a lo estipulado en la presente Norma, es decir, los tipos, elementos, atributos y enumeraciones DEBEN ser los indicados en la lista del Diccionario. Sin embargo, algunas enumeraciones se definen sin restricciones y pueden ser limitadas o ampliadas por cada una de las oficinas.

17.

Los usos que se ajusten a la presente Norma DEBEN realizarse con arreglo a las directrices estipuladas en la presente Norma o DEBEN ser una extensión de un XSD que se ajuste a las directrices de la presente Norma.

18.

Los documentos XML que se ajusten a la presente Norma DEBEN estar bien formados y validados por los XSD del Apéndice B.

19.

Queda entendido que en la presente Norma no se pueden incluir todos los elementos exigidos por todas las oficinas de diseños industriales, por lo que se permite la utilización de elementos específicos de cada oficina, como se señala, en la sección “Denominación de tipos y elementos específicos de oficinas”.

20.

El lenguaje de definición de esquemas XML del W3C ha pasado a ser el lenguaje de esquema de mayor aceptación. Aunque existen otros lenguajes de esquema que ofrecen sus propias ventajas y desventajas, todas las normas de diseño de esquemas XML DEBEN basarse en las recomendaciones de esquemas XML del W3C: Esquema XML Parte 1: Estructuras y Esquema XML, Parte 2: Tipos de datos. Todos los esquemas y mensajes DEBEN basarse en la serie de especificaciones técnicas del W3C que tienen carácter de recomendación.

21.

DEBERÍA evitarse la redefinición de tipos de datos predefinidos de XSD.

22.

DEBE utilizarse la Norma ST.3 de la OMPI para el país de prioridad, la Parte Contratante, la oficina receptora y la oficina designada.

23.

DEBE utilizarse la Norma ISO 3166 para los códigos de dirección de países, los códigos de países en los que se hayan expuesto los diseños y las nacionalidades.

24.

DEBE utilizarse la Norma ISO/IEC 10646 – UCS – Unicode UTF‑8 para la serie de caracteres.

25.

DEBE utilizarse la Norma ISO 639‑1 (Códigos de 2 letras para el idioma) para los códigos de idioma.

26.

DEBE utilizarse la Norma ISO 8601 relativa a la fecha y hora normalizadas a nivel internacional para la representación de la fecha y la hora. Los tipos de datos de esquema del W3C contienen la fecha y la hora y DEBEN ser utilizados con preferencia a la ISO 8601, cuando existan discrepancias a ese respecto.

27.

DEBE utilizarse la Norma ISO 4217‑Alpha (códigos de 3 letras para las divisas) para los códigos de divisas.

Caracteres

28.

En la presente Norma se recomienda utilizar exclusivamente Unicode. Puede ser útil incluir entidades de caracteres para los que aún no se encuentren en Unicode. El uso de esas entidades requiere la creación de glifos para la presentación, que aún no existen. Para más información sobre las entidades de caracteres véase http://www.w3.org/XML/Core/2002/10/charents-20021023.

29.

En la primera línea del fichero de los documentos DEBE figurar una declaración XML.

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

Cabe observar que en la presente Norma sólo se recomienda el formato UTF‑8. No obstante, en el caso de la escritura ideográfica, Unicode en el formato UTF‑8 PUEDE producir excepcionalmente archivos extensos, ya que la codificación PUEDE utilizar hasta cuatro octetos por carácter. En esos casos las oficinas nacionales PUEDEN optar por un sistema de codificación que reduzca razonablemente el tamaño de los archivos. Las oficinas que opten por esta solución, DEBERÁN estar preparadas para entablar consultas con sus interlocutores y notificarlo públicamente de manera adecuada.

30.

Los caracteres permitidos en un documento XML son los que se especifican en la Recomendación para la versión 1.0 del XML del Consorcio W3C, que se suscriben en la presente Norma, con la salvedad de que para los caracteres utilizados en los tipos, elementos o atributos descritos en la presente Norma se utilizará únicamente la siguiente serie de caracteres: {a-z, A-Z, 0-9, punto (.), guión (‑) y subrayado (_)}.

Generalidades en relación con el XML

Limitaciones en materia de denominación y modelos

Limitaciones en materia de denominación

31.

En cada entrada del diccionario se DEBE definir una única ruta totalmente cualificada para un elemento o atributo.

Limitaciones en materia de modelos

32.

Las bibliotecas y esquemas DEBEN utilizar únicamente tipos de datos aprobados.

33.

NO DEBE utilizarse contenido mixto en esquemas de datos céntricos salvo cuando figuren en el elemento xsd:documentation.

Esquema de reutilización

34.

Todas las declaraciones de tipo DEBEN ser globales.

Esquema de espacios de nombres

Declaración de espacios de nombres

35.

Todo módulo de esquema, excepto los módulos de esquemas internos, DEBE tener un espacio de nombre declarado utilizando el atributo xsd:targetNamespace.

36.

En todos los esquemas XML se DEBE declarar el espacio de nombres del esquema del W3C. En los esquemas se DEBE declarar un espacio de nombres de destino.

37.

DEBE utilizarse la calificación de los espacios de nombres para la estructuración del esquema del W3C.

38.

Toda versión definida o utilizada de una serie de esquemas DEBE tener su propio espacio de nombres que será exclusivo.

39.

Los espacios de nombres publicados nunca DEBEN ser modificados.

40.

No DEBERÁ haber espacios de nombres por defecto. Es decir, por ejemplo, tanto el XMLSchema como el targetNamespace DEBEN calificarse explícitamente. Este enfoque, aunque resulta bastante complejo, es más coherente para todos los tipos de esquemas que poseen uno o varios espacios de nombres o que carecen de ellos. Por ejemplo:

<?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.

Para ocultar o mostrar los espacios de nombres en los documentos, se DEBERÁ utilizar el atributo de cambio binario: elementFormDefault (forma de atributo por defecto) del elemento <xsd:schema> (calificado o sin calificar).

42.

En las referencias de esquemas externos se DEBERÍA utilizar el concepto de “inclusión”. Los esquemas incluyentes e incluidos DEBEN tener el mismo espacio de nombres de destino.

43.

En aras de la simplicidad, DEBERÍA preferirse una configuración de un único espacio de nombres. PUEDEN utilizarse varios espacios de nombres a los fines de la extensión (nacionalización).

Convenciones en materia de denominación

Normas para la denominación de etiquetas XML

44.

Las convenciones para la denominación de etiquetas XML se basan en los conceptos definidos en la Parte 5 de la Norma ISO 11179. Los nombres de elementos, atributos y tipos DEBERÍAN consistir en la clase de objeto, el término de propiedad y el término de representación.

a) La clase de objeto identifica el concepto primario del elemento, hace referencia a una actividad u objeto en contexto práctico y PUEDE consistir en una, dos o tres palabras.

b) El término de propiedad identifica las características de la clase de objeto. El nombre de un término de propiedades DEBERÁ aparecer naturalmente en la definición de la etiqueta y PUEDE consistir en una, dos o tres palabras. El nombre del término de propiedad DEBERÁ ser único en el contexto de una clase de objeto pero PODRÁ volver a ser utilizado en distintas clases de objetos.

c) Si en el término de representación se utiliza la misma palabra que la última palabra utilizada en el término de propiedad, DEBERÁ omitirse el término de representación.

d) DEBERÍA omitirse la clase de objeto y los términos de representación cuando el término de propiedad sea utilizado corrientemente y baste de por sí para expresar el concepto sin que exista confusión respecto de su contexto.

e) Por ejemplo (clase de objeto + término de propiedad + término de representación):

  • 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.

Los nombres de elementos, atributos y tipos DEBEN ser únicos. Los nombres DEBERÍAN ser concisos y NO DEBERÍAN contener palabras redundantes concatenadas; asimismo, DEBEN ser suficientemente claros de por sí y estar muy estructurados.

46.

Los nombres de elementos, atributos y tipos y todos sus componentes DEBEN figurar en singular, salvo que el concepto en sí se exprese en plural.

47.

Los nombres de elementos, atributos y tipos DEBEN contener únicamente nombres, adjetivos y en último término verbos. DEBEN suprimirse palabras tales como “and”, “of” y “the”, salvo cuando esa supresión pueda inducir a conclusiones erróneas en relación con el nombre. Por ejemplo, IndicationProduct, OpenToLicencingIndicator.

48.

Los nombres de elementos, atributos y tipos NO DEBEN ser traducidos, modificados ni sustituidos por motivo alguno.

49.

Los nombres de elementos, atributos y tipos DEBEN estar compuestos por palabras del idioma inglés, utilizando la grafía inglesa básica que figura en el Diccionario Inglés Oxford, incluidas las etiquetas específicas de oficinas (véanse las excepciones correspondientes a las siglas en el párrafo 57).

50.

Los nombres de elementos DEBEN figurar en el estilo upper camel case (UCC). En este estilo figura en mayúsculas la primera letra de cada palabra que compone el nombre. Por ejemplo, AddressCountryCode.

51.

Los nombres de tipos DEBEN figurar en UCC + Suffix Type. Por ejemplo, LanguageCodeType.

52.

Los nombres de atributos DEBEN figurar en lower camel case (LCC). En este estilo se pone en mayúsculas la primera letra de cada palabra excepto la de la primera palabra. Por ejemplo, currencyCode="EUR".

53.

La enumeración de valores o el texto de la lista de códigos DEBERÍA ser breve pero suficiente desde el punto de vista semántico y figurar en inglés cuando no exista una lista de códigos estándar. Los valores y códigos DEBERÍAN extraerse del lenguaje corriente del ámbito de la propiedad industrial.

54.

Se recomienda establecer un límite de 35 caracteres para el nombre. Cuando se repita la misma palabra en un nombre de un elemento, DEBERÍA suprimirse la segunda vez que aparezca o las veces posteriores.

55.

Los nombres de elementos, atributos y tipos NO DEBEN contener puntos (.), espacios u otros separadores o caracteres no permitidos para los nombres de XML en la recomendación 1.0 para XML del W3C a excepción de lo estipulado en la presente Norma. Por ejemplo, prefijos de oficinas o dominios (XX_UCC con XX en el código de la Norma ST.3).

56.

Los caracteres utilizados en valores de enumeración descritos en la presente norma se limitan a la serie siguiente: {a-z, A-Z, 0-9, punto (.), coma (,), espacios, guión (‑) y subrayado (_)}.

Siglas y abreviaturas

57.

Los nombres de elementos, atributos y tipos XML NO DEBEN utilizar siglas, abreviaturas u otro tipo de acrónimos, excepto los especificados en la presente Norma o los que figuran en el Apéndice D.

58.

DEBEN utilizarse siempre las siglas y abreviaturas enumeradas en el Apéndice D en lugar del nombre completo.

59.

Las siglas y abreviaturas que figuran al comienzo de una declaración de atributos DEBEN figurar en minúsculas. Todas las demás siglas y abreviaturas utilizadas en la declaración de atributos DEBEN figurar en mayúsculas.

60.

Las siglas DEBEN figurar en mayúsculas para todas las declaraciones de elementos y definiciones de tipo.

Normas para la denominación de archivos de esquemas XML

61.

Gracias a estas convenciones se garantizará que los objetos sean almacenados de manera coherente, uniforme y exhaustiva, y estén disponibles para todo tipo de almacenamiento y reutilización.

62.

Se recomienda aplicar una regla de denominación en seis partes para los nombres de esquemas y hojas de estilo. A continuación se expone la regla de denominación en seis partes:

Parte Descripción Sintaxis
[Oficina] Se utilizará en caso de objetos específicos de oficinas o de unión de varios códigos de oficinas. AA (código de la Norma ST.3). Se suprimirá en el caso de la versión genérica de la Oficina. Para las organizaciones no identificadas en la Norma ST.3 de la OMPI o para las empresas, NO DEBERÍAN utilizarse códigos de dos letras, sino códigos compuestos por tres o cuatro UCC.
- Delimitador. Un único guión.
[Dominio] Indicación del dominio.

Aaa (nombre de longitud variable, longitud máxima de 8 caracteres).

Ejemplo:
RCD = Registered Community Design (diseño comunitario registrado)

- Delimitador. Un único guión.
Nombre del mensaje o servicio

Nombre del mensaje o servicio en UCC

Ejemplo: RCDDownloadClassTerm

- Delimitador. Un único punto.
Versión

Existen dos opciones:

1. Versión y sub-versión (separada de la parte anterior por un guión).

2. Versión por fecha (por ejemplo ssaa‑mm‑dd).

. Delimitador. Un único guión.
Extensión Extensión de archivo (separada de la parte anterior por un punto).

Aaa (de dos a cuatro caracteres).

Ejemplo: xsd, xml, xsl

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

[Oficina] [Dominio] Mensaje Servicio Versión Extensión
EM- RCD eFiling V1-1 .xsd
RCDDownload 2007-02-25 .xml

Nota: El campo que figura entre corchetes [ ] es OPCIONAL.

63.

Los nombres de archivos DEBERÍAN basarse en las normas de denominación de etiquetas mencionadas anteriormente. Sin embargo, cabe definir localmente un mapa si no pueden aplicarse las normas debido a limitaciones técnicas. Ese tipo de normas locales DEBEN estar bien definidas y publicadas para todos los usuarios potenciales.

64.

DEBERÍAN modificarse las versiones de los nombres de archivos de esquemas cuando se actualice un esquema modular. Con respecto a la versión más reciente del esquema XML, las oficinas PUEDEN proporcionar dos tipos de la versión más reciente en su sitio Web: un esquema con un número de versión adecuado (por ejemplo, WIPOST3Code‑V2005-05‑21.xsd, st36for66‑V1‑0.xsd) y un esquema que no tenga número de versión (por ejemplo, WIPOST3Code.xsd, st36for66.xsd), que es una copia de (o se refiere a) la versión más reciente del esquema XML. También puede hacerse referencia a la versión más reciente indicando el esquema con el número de versión más reciente o el esquema que no tiene número de versión y es una copia de la versión más reciente para evitar modificar los códigos aplicados por la oficina cuando se actualice el esquema.

Normas varias de XSD

65.

No DEBE definirse la limitación de la longitud de campo para el esquema XML de la Norma ST.86, pero PUEDE realizarse en el caso de los esquemas de aplicación.

66.

El elemento <any> DEBERÍA ser utilizado para ofrecer una extensión y poder incluir elementos adicionales en el esquema XML de la Norma ST.86 (Apéndice B). No DEBE ser utilizado en los esquemas de aplicación.

67.

Los elementos DEBERÍAN ser declarados con indicadores de ocurrencia. Estos indicadores no deberían ser declarados explícitamente cuando el valor exigido sea el valor por defecto. Por ejemplo:

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

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

68.

El contenido o el valor de las etiquetas y atributos puede figurar en cualquier idioma, excepto las enumeraciones.

69.

No DEBERÁ incluirse en el propio esquema ningún historial de su revisión. La mención que se haga al historial de revisión y el número y la fecha de la versión más reciente del esquema sólo DEBERÍAN figurar en el esquema XLM. El historial de revisión DEBERÍA contener información documental sobre los cambios, con la fecha y una descripción de cada uno de ellos, por orden cronológico inverso y debería publicarse en el sitio Web de la oficina. Por ejemplo:

<xs:annotation>

<xs:documentation>WIPO Standard ST.86 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.

Los puntos de contacto DEBERÁN incluirse en el prólogo. Por ejemplo:

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

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

Denominación de tipos y elementos específicos de oficinas

71.

DEBERÍA establecerse un espacio de nombre para elementos específicos de oficinas, en el que el código de oficina (Norma ST.3) pase a ser el prefijo para identificar elementos que figuran en ese espacio de nombres. Por ejemplo:

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

<kr:element name="Bibliographic">

< kr:complexType mixed="true">

<kr:choice minOccurs="0" maxOccurs="unbounded">

<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.

Los tipos que no estén definidos en la norma pueden ser definidos como específicos de oficinas. Los nombres de tipos DEBERÍAN tener un prefijo específico de la organización seguidos de un único guión. En el caso de las oficinas de diseños industriales, los tipos DEBERÍAN ir precedidos del código de dos letras de la oficina tal y como se estipula en la Norma ST.3 de la OMPI.

73.

Las organizaciones/oficinas no señaladas en la Norma ST.3 de la OMPI y las empresas no DEBERÍAN utilizar códigos de dos letras, sino códigos compuestos por tres o cuatro letras mayúsculas.

74.

Como alternativa, DEBERÍA establecerse un único espacio de nombres para elementos específicos de oficinas, cuando el código de país o el símbolo de la empresa pase a ser el prefijo que identifique los elementos que figuren en ese espacio de nombres.

Entidades externas

75.

Una entidad externa es un objeto que acompaña un documento XML que es referenciado en el documento. Las entidades externas forman parte esencial de los documentos de diseños industriales. Sin ellas, los documentos XML no pueden procesarse, presentarse o comprenderse adecuadamente.

76.

En el ámbito de los diseños industriales, las entidades externas son frecuentemente imágenes, normalmente del diseño industrial. Las entidades externas que sean imágenes del diseño industrial DEBERÁN ajustarse a uno de los siguientes perfiles publicados por la OMPI en su sitio Web.2

  • JPEG
  • PNG
  • TIFF
  • GIF

77.

Se pueden incorporar imágenes en un documento XML como imágenes binarias codificadas en base64Binary, que es el tipo de datos normalizados del esquema XML del W3C, así como referencias a archivos de imágenes externos, es decir, entidades externas. No obstante, cuando haya imágenes, se DEBERÁ hacer referencia a ellas como entidades externas.

[Fin de la Norma]


1  Nota editorial: el sistema ebXML fue publicado en 1999 como iniciativa del Centro de las Naciones Unidas para la Facilitación del Comercio y las Transacciones Electrónicas (UN/CEFACT) y la Organization for the Advancement of Structured Information Standards (OASIS).

2  En la actualidad, el Equipo Técnico de Normas sobre Marcas del SDWG está preparando, para su adopción como Norma de la OMPI, una recomendación para la gestión electrónica de los elementos figurativos de las marcas. Dicha recomendación podría aplicarse también a los diseños industriales.