СТАНДАРТ ST.86
|
|
Версия 1.0
РЕКОМЕНДАЦИИ ПО ОБРАБОТКЕ ИНФОРМАЦИИ О ПРОМЫШЛЕННЫХ ОБРАЗЦАХ С ИСПОЛЬЗОВАНИЕМ XML (EXTENSIBLE MARKUP LANGUAGE)
Стандарт одобрен Рабочей группой по стандартам и документации ВОИС на девятой сессии 21 февраля 2008
ВВЕДЕНИЕ
1. Настоящий стандарт содержит рекомендации по использованию XML (eXtensible Markup Language) ресурсов для подачи заявок, обработки, публикации и обмена для всех видов информации по промышленным образцам. В основном, он основан на стандартах ВОИС СT.36 и СТ.66
2. Понятие «XML ресурсы» относится к любым компонентам, используемым для создания и эксплуатации XML реализации. Для получения более полной информации о W3C (Консорциум всемирной паутины) см. http://www.w3c.org/.
3. Понятие «XML схема» означает язык для описания структуры и ограничения содержания XML документа.
4. Существует множество языков схем, основанных на XML. Данный стандарт рекомендует только язык XML схем консорциума W3C. Понятие «Определение XML схемы (XSD)») есть частный случай XML схемы, написанный на языке XML схем консорциума W3C. XSD определяет классы экземпляров XML документа в терминах ограничений того, какие элементы и атрибуты могут появляться (использоваться), их взаимных связей, какие типы данных они могут содержать, и т.д.
5. XML не может быть использован per se как основа для обработки информации по промышленным образцам. Поэтому данный стандарт определяет элементы и их обобщенные идентификаторы, или «тэги», и атрибуты для разметки документов, касающихся промышленных образцов. Таким образом, данный стандарт устанавливает на определенном семантическом уровне использование и именование типов, элементов и атрибутов, которые формируют различные типы документов, рассматриваемые в нем.
6. Целью данного стандарта является создание логических, системно-независимых структур для обработки документов по промышленным образцам, как текстовых, так и графических данных. Данный стандарт ссылается на стандарты ISO для кода страны (ISO3166), языкового кода (ISO639), кода валют (ISO4217) и коды СТ.3 как на внешнюю схему.
ОПРЕДЕЛЕНИЯ И ТЕРМИНЫ
7. Ключевые слова ДОЛЖЕН (MUST), НЕ ДОЛЖЕН (MUST NOT), НАДЛЕЖИТ (SHALL) СЛЕДУЕТ (SHOULD), НЕ СЛЕДУЕТ (SHOULD NOT), МОЖЕТ (MAY) и НЕОБЯЗАТЕЛЬНЫЙ (OPTIONAL) в данном документе должны пониматься так, как описано в Запросе на комментарии (Request For Comments (RFC)) 2119 Оперативной группы по Интернет разработкам (Internet Engineering Task Force (IETF)). Если эти слова написаны не заглавными буквами, то они используются в обычных значениях.
(a) Пример – Представление определения или правила. Примеры информативны.
(b) [Примечание] – Пояснительная информация. Примечания информативны.
8. Для целей данных рекомендаций выражение:
(a) «промышленные образцы» включает двумерные и трехмерные особенности формы и поверхности объектов, и, таким образом, охватывает обе концепции «образца» и «модели» в том случае, если между ними устнавливается различие; термин «промышленные образцы» не включает патенты на промышленные образцы, для которых приментяется Стандарт ВОИС СТ.9;
(b) «документы, относящиеся к образцу» означает опубликованные документы, касающиеся регистрации или представления для регистрации промышленного образца, а также впоследствии опубликованные заявки;
(c) «Сертификат на образец» означает официальный документ, выданный владельцу образца, подтверждающий, что его или ее образец был зарегистрирован или возобновлен, т.е. был внесен в реестр промышленных образцов данной страны или организации, или был возобновлен (данное определение также включает «свидетельства» или «выписки из реестра», выданные ведомствами по промышленной собственности, например, для представления в суд);
(d) «Официальный бюллетень» означает официальную публикацию, содержащую извещения, касающиеся промышленных образцов и сделанные в соответствии с требованиями национального или регионального законодательства по промышленной собственности или международных конвенций или договоров по промышленной собственности;
(e) «Запись в официальном бюллетене» означает размещенное в официальном бюллетене уведомление, содержащее полную информацию, включая библиографические данные, касающееся регистрации промышленного образца или представления для регистрации или последующей регистрации;
(f) «ИНИД - INID» является аббревиатурой «Международно-согласованных номеров для идентификации (библиографических) данных - Internationally agreed Numbers for the Identification of (bibliographic) Data»
9. Разметка определяется как текст, который добавлен к содержанию документа и описывает структуру и другие атрибуты документа, в системно-независимой форме, в независимости от обработки, которой они МОГУТ подвергаться.
10. Другие определения см. в спецификациях XML на http://www.w3c.org/TR/2004/REC-xml11-20040204/.
ОБЛАСТЬ ПРИМЕНЕНИЯ СТАНДАРТА
11. Настоящий стандарт содержит рекомендации для национальных, региональных и международных организаций, которые, основываясь на национальных законах по промышленной собственности или международных конвенциях по промышленной собственности, публикуют извещения как по заявкам на промышленные образцы, так и по регистрациям промышленных образцов.
12. Данный стандарт определяет XML ресурсы для обмена и обработки документов по промышленным образцам и записей о произведенных действиях. Модель схемы различных типов документов, касающихся промышленных образцов, и записей о произведенных действиях см. в Приложении 2.
13. Настоящие рекомендации касаются только XML схемы консорциума W3C. Несмотря на то, что XMLDTD могут быть получены автоматически из XML схемы, они не соответствуют данному стандарту, по определению, никакие DTD не могут соответствовать данному стандарту. Спецификацию XML схемы см. на http://www.w3.org/XML/Schema#dev.
ССЫЛКИ
14. В данном стандарте используются ссылки на следующие стандарты и документы
(a) Стандарт ВОИС СТ.3: Рекомендуемый стандарт на двубуквенные коды для представления стран, административных единиц и межправительственных организаций;
(b) Стандарт ВОИС СТ.36 Рекомендации по обработке патентной информации с использованием XML;
(c) Стандарт ВОИС СТ.66 Рекомендации по обработке информации по товарным знакам с использованием XML;
(d) Стандарт ВОИС СТ.80 Рекомендации, относящиеся к библиографическим данным о промышленных образцах;
(e) Стандарт ВОИС СТ.81 Рекомендации по содержанию и расположению публикаций в бюллетене промышленных образцов;
(f) Международная классификация промышленных образцов в соответствии с Локарнским соглашением
(g) ISO/IEC 11179-5 Информационные технологии. Реестры метаданных (MDR). – Часть 5: Принципы именования и идентификации;
Международная классификация товаров и услуг для международной регистрации знаков (Ниццкая классификация)
(h) ISO 3166-1 – Коды для представления названий стран и единиц их административно-территориального деления – Коды стран;
(i) ISO 639-1 – Коды для представления названий языков – Часть 1: Alpha2-код;
(j) ISO 4217 – Коды для представления валют и активов; Руководство по информации и документации в области промышленной собственности
(k) ISO 8601 – Элементы даты и форматы обмена – Обмен информацией – Представление даты и времени;
(l) ISO/IEC 10646 – Информационные технологии – Универсальный многооктетный (многобайтовый) кодированный набор символов (UCS);
(m) ebXML (Electronic Business using XML – Электронные деловые операции с использованием XML) при поддержке UN/CEFACT (United Nations Centre for Trade Facilitation and Electronic Business – Центр ООН по упрощению процедур торговли и электронным деловым операциям) и OASIS (Organization for the Advancement of Structured Information Standards – Организация по продвижению стандартов структурированной информации) – модульный набор спецификаций для e-Бизнеса в Интернет.1
(n) UN/CEFACT – Правила именования XML и Правила оформления, Версия 2.0;
(o) OASIS UBL Именование и Правила оформления;
(p) Запрос на комментарии (RFC) 2119 Оперативной группы по Интернет разработкам (IETF).
ТРЕБОВАНИЯ СТАНДАРТА
15. Основой данного стандарта является XML словарь СТ.86, приведенный в приложении A.
16. Словарь ДОЛЖЕН использоваться так, как определено в данном стандарте, то есть типы, элементы, атрибуты и
перечни значений ДОЛЖНЫ быть такими, как указано в списке Словаря. Однако некоторые перечни значений определены как открытые и могут быть ограничены или расширены при использовании в практике ведомств.
17. Разработка в соответствии с данным стандартом ДОЛЖНА осуществляться, следуя указаниям данного стандарта, или ДОЛЖНА являться расширениями соответствующих ему XSD, в соответствии с указаниями данного стандарта.
18. XML сущности в соответствии с данным стандартом ДОЛЖНЫ быть хорошо согласованы и основаны на XSD, приведенными в Приложении B.
19. Принимая во внимание то, что настоящий стандарт не может включить все элементы, необходимые ведомствам по промышленным образцам, такая схема разработки дает ведомствам возможность вводить свои специфические элементы, как описано ниже в разделе «Именование специфических для ведомств типов и элементов».
20. Язык определений схемы XML консорциума W3C является общепринятым языком схем, что обуславливает его наиболее широкое применение. Хотя другие существующие языки схем имеют свои достоинства и недостатки, все правила составления XML схем ДОЛЖНЫ основываться на Рекомендациях консорциума W3C для XML схем: XML схема Часть 1: Структуры и XML схема, Часть 2 типы данных. Все схемы и сообщения ДОЛЖНЫ основываться на комплекте (наборе) технических требований W3C, имеющих статус рекомендаций.
21. Переопределения XSD, встроенных в типы данных, СЛЕДУЕТ избегать.
22. Стандарт ВОИС СТ.3 ДОЛЖЕН использоваться для страны приоритета, страны старшинства и договаривающихся государств.
23. ISO 3166 ДОЛЖЕН использоваться для кодирования страны в адресе, кодирования страны выставки и указания гражданства.
24. ISO/IEC 10646 – UCS – Unicode UTF-8 ДОЛЖЕН использоваться как набор символов.
25. ISO 639-1 (Двубуквенные коды языков) ДОЛЖЕН использоваться для кодирования языков.
26. ISO 8601 – Международный стандарт дат и указания времени ДОЛЖЕН использоваться для указания даты и времени. Схема типов данных консорциума W3C включает дату и время и ее СЛЕДУЕТ использовать в случае конфликта с ISO 8601.
27. ISO 4217-Alpha (трехбуквенные коды валют) ДОЛЖЕН использоваться для кодирования валют.
1 Замечание редактора: ebXML был опубликован в 1999 по инициативе Центра ООН по упрощению процедур торговли и электронным деловым операциям (UN/CEFACT) и Организация по продвижению стандартов структурированной информации (OASIS). Руководство по информации и документации в области промышленной собственности
Символы
28. Настоящий стандарт рекомендует только таблицу Unicode. Представляется целесообразным добавить символьные сущности для тех символов, которые еще не указаны в Unicode. Использование этих сущностей требует создания глифов для представления, которые еще не существуют. Более подробную информацию см. на http://www.w3.org/XML/Core/2002/10/charents-20021023
29. Сущности документов ДОЛЖНЫ включать первой строкой файла декларации XML.
В данном стандарте рекомендуется только UTF-8. Однако в случае идеографических шрифтов, Unicode в UTF-8 МОЖЕТ генерировать исключительно большие файлы, так как кодирование МОЖЕТ использовать до четырех байтов на символ. В таких случаях национальные ведомства МОГУТ выбрать тот вариант кодирования, который сведет файлы к допустимому для управления размеру. Ведомствам, которые приняли такое решение, СЛЕДУЕТ быть готовыми проводить консультации со своими партнерами по информационному обмену и дать соответствующие (достаточные) публичные уведомления.
30. Символы, которые могут использоваться в XML документах, определены в Рекомендациях W3C по XML 1.0 и поддерживаются настоящим стандартом со следующими исключениями. Символы, используемые для имен типов, элементов или атрибутов, описанных в настоящем стандарте, ограничиваются следующим множеством: {a-z, A-Z, 0-9, точка (.), тире (-) и подчеркивание (_)}. Руководство по информации и документации в области промышленной собственности
Основные конструкции XML
Правила именования и моделирования
Правила именования
31. Любое имя точки входа словаря ДОЛЖНО определять один и только один полностью определенный путь к элементу или атрибуту.
Правила моделирования
32. Библиотеки и схемы ДОЛЖНЫ использовать только принятые типы данных.
33. В схеме, ориентированной на работу с данными, НЕ ДОЛЖНО использоваться смешанное содержание, за исключением случая, когда оно содержится в элементе xsd:documentation.
Схема возможности повторного использования
34. Все описания типов должны быть глобальными.
Схема пространства имен
Описание пространств имен
35. Любой модуль схемы, кроме модулей внешних схем, ДОЛЖЕН иметь имя, описанное с использованием атрибута xsd:targetNamespace.
36. Все XML схемы ДОЛЖНЫ описывать пространство имен W3C схемы. Схемы ДОЛЖНЫ описывать целевое пространство имен.
37. Для конструкции W3C схемы ДОЛЖНО использоваться уточнение пространства имен.
38. Любая определенная или используемая версия множества (набора) схем ДОЛЖНА иметь свое уникальное пространство имен.
39. Опубликованные пространства имен ДОЛЖНЫ быть неизменными во всех случаях.
40. Пространства имен НАДЛЕЖИТ не устанавливать по умолчанию. Так, например, как XML схема, так и целевое пространство имен ДОЛЖНЫ быть подробно уточнены. Такой подход, несмотря на свою некоторую перегруженность, наилучшим образом совмещается со всеми типами схем: без пространства имен, с одним или несколькими целевыми пространствами имен. Например:
targetNamespace=”http://www.wipo.int/standards/XMLSchema”
xmlns:lib=”http://www.wipo.int/standards/XMLSchema”
elementFormDefault=”qualified”>
41. Для того чтобы скрыть или показать пространства имен в конкретных документах, СЛЕДУЕТ использовать атрибут бинарный переключатель: elementFormDefault элемента , который определен или не определен.
42. При ссылке на внешнюю схему СЛЕДУЕТ использовать конструкцию «Включение» (“Include”). Включающая и включенная схемы ДОЛЖНЫ иметь одинаковые пространства имен.
43. Для простоты СЛЕДУЕТ предпочитать использование одинарной конфигурации пространства имен. Множественные пространства имен МОГУТ использоваться для создания национальных расширений.
Соглашения об именовании
Правила именования тэгов XML Руководство по информации и документации в области промышленной собственности
44. Соглашения об именовании XML тэгов основаны на концепциях, определенных в ISO 11179 Часть 5. Имена элементов, атрибутов и типов СЛЕДУЕТ составлять из Класса объекта (Object Class), Свойства объекта (Property Term) и Представления объекта (Representation Term).
(a) Класс объекта определяет основную идею элемента. Он относится к деятельности или объекту в контексте деловых операций и МОЖЕТ состоять из одного, двух или трех слов.
(b) Свойство объекта определяет характеристики Класса объекта. Имя Свойства объекта НАДЛЕЖИТ использовать в определении тэгов, и оно может состоять из одного, двух или трех слов. Имя Свойства объекта НАДЛЕЖИТ использовать один раз в контексте одного Класса объекта, в других Классах объекта оно МОЖЕТ использоваться повторно.
(c) Если Представление объекта использует то же слово, которое является последним в имени Свойства объекта, то Представление объекта НАДЛЕЖИТ опустить.
(d) Класс объекта и Представление объекта СЛЕДУЕТ опускать, если термин Свойства объекта сам по себе часто используется и достаточно выражает идею, не вызывая путаницы в контексте.
(e) Например (Класс объекта + Свойство объекта + Представление объекта):
-
ApplicantNationalityCode: Applicant(Класс объекта) + Nationality(Свойство объекта) + Code(Представление объекта)
-
ViewFilename: View(Класс объекта) + Filename(Свойство объекта) + Text(Представление объекта, опущено)
-
FilingDate: Mark(Класс объекта, опущено) + FilingDate(Свойство объекта)+ Date(Представление объекта, опущено)
45. Имена элементов, атрибутов и типов ДОЛЖНЫ быть уникальны. Именам СЛЕДУЕТ быть краткими и НЕ СЛЕДУЕТ содержать последовательных избыточных слов, также они ДОЛЖНЫ быть самоописывающими и по возможности хорошо структурированными.
46. Имена элементов, атрибутов и типов, как и все их компоненты, ДОЛЖНЫ быть в единственном числе, если сама концепция не является множественной.
47. Имена элементов, атрибутов и типов ДОЛЖНЫ содержать только существительные, прилагательные и глаголы в основной форме. Такие слова как “and (союз)”, “of (предлог)”, “the (артикль)” ДОЛЖНЫ удаляться, кроме тех случаев, когда это удаление делает имя вводящим в заблуждение. Например, IndicationProduct (Указание продукта), OpenToLicencingIndicator (Индикатор открытой лицензии)
48. Имена элементов, атрибутов и типов НЕ ДОЛЖНЫ переводиться, изменяться или перемещаться с какой бы то ни было целью.
49. Имена элементов, атрибутов и типов ДОЛЖНЫ быть составлены из слов на английском языке, с использованием основного написания, приведенного в словаре Oxford English Dictionary, в том числе и тэги, определяемые ведомством (кроме аббревиатур, см. ниже параграф 57).
50. Имена элементов должны быть в стиле UCC (upper camel case). Стиль UCC означает, что каждое из слов, составляющих имя, начинается с заглавной буквы. Например, AddressCountryCode.
51. Имена типов ДОЛЖНЫ быть в UCC + Suffix Type. Например, LanguageCodeType.
52. Имена атрибутов ДОЛЖНЫ быть в стиле LCC (lower camel case). Стиль LCC означает, что каждое из слов, составляющих имя, кроме первого, начинается с заглавной буквы. Например, currencyCode=”EUR”.
53. Перечисление значений или текст перечня кодов СЛЕДУЕТ делать кратким, но семантически достаточным, на английском языке, в том случае, если нет стандартного перечня кодов. Значения и коды СЛЕДУЕТ заимствовать из обычного делового языка области интеллектуальной собственности.
54. Рекомендуется ограничивать имя 35 символами. В случае если одно слово повторяется в имени элемента, второе и последующие вхождения СЛЕДУЕТ опускать. Руководство по информации и документации в области промышленной собственности
55. Имена элементов, атрибутов и типов НЕ ДОЛЖНЫ содержать точек (.), пробелов и иных разделителей, не предусмотренных консорциумом W3C XML 1.0 для имен XML, кроме случаев, определенных в данном стандарте. Например, префиксы ведомств или доменов (XX_UCC, где XX – код СТ.3).
56. Символы, используемые в именах перечислимых значений, описанных в данном стандарте, ограничиваются следующим множеством: {a-z, A-Z, 0-9, точка (.), запятая (,), пробел, тире (-) и подчеркивание (_)}.
Акронимы и сокращения
57. Имена элементов, атрибутов и типов НЕ ДОЛЖНЫ использовать акронимы, сокращения или иные словесные усечения, кроме тех, которые указаны в данном стандарте или перечислены в Приложении D.
58. Акронимы и сокращения, перечисленные в Приложении D, ДОЛЖНЫ всегда использоваться вместо полного расширенного названия.
59. Акронимы и сокращения в начале объявления атрибута ДОЛЖНЫ быть записаны строчными символами (буквами). Все другие акронимы и сокращения ДОЛЖНЫ быть записаны заглавными символами (буквами).
60. При объявлении элементов или описании типов все символы акронимов ДОЛЖНЫ быть заглавными.
Правила именования файлов XML схемы
61. Данные соглашения позволяют гарантировать, что объекты будут храниться в порядке, обеспечивающем последовательность, однородность и полноту, и будут пригодны для всех аспектов хранения и повторного использования.
62. Рекомендуется для имен файлов схемы и макета страницы (style sheet) следовать шестикомпонентному правилу именования. Шестикомпонентное правило именования проиллюстрировано ниже (смотрите в скачиваемом файле).
|
|
