СТАНДАРТ ST.66
|
|
Версия 1.1
РЕКОМЕНДАЦИИ ПО ОБРАБОТКЕ ИНФОРМАЦИИ ПО ТОВАРНЫМ ЗНАКАМ С ИСПОЛЬЗОВАНИЕМ XML (EXTENSIBLE MARKUP LANGUAGE)
Редакция одобрена Оперативной группой по пересмотру стандарта ВОИС СT.66 3 декабря 2007
ВВЕДЕНИЕ
1. Настоящий стандарт содержит рекомендации по использованию XML (eXtensible Markup Language) ресурсов для подачи заявок, обработки, публикации и обмена для всех видов информации по товарным знакам. В основном, он основан на TM-XML, модели для товарных знаков, размещенной на http://www.tm-xml.org/, DTD для электронного взаимодействия в рамках Мадридской системы (далее MECA) и стандарте ВОИС СT.36.
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) «знак» означает товарный знак, знак обслуживания или другой различительный знак в соответствии с определением соответствующего законодательства, включая, но не ограничиваясь коллективными знаками, сертификационными знаками или гарантийными знаками;
(b) «сертификат» означает официальный документ, который выдается владельцу знака, удостоверяющий, что его/ее знак зарегистрирован национальным ведомством или некоторой организацией, или что такая регистрация обновлена или изменена (настоящее определение также включает «сертификаты» или «выписки из реестра», выдаваемые ведомством, например, для представления в суде);
(c) «бюллетень» означает официальную публикацию, содержащую извещения, касающиеся товарных знаков и сделанные в соответствии с требованиями национального законодательства по промышленной собственности или международных конвенций или договоров по промышленной собственности;
(d) «ИНИД - 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) Стандарт ВОИС СТ.60 Рекомендации, относящиеся к библиографическим данным о товарных знаках;
(d) Стандарт ВОИС СТ.62 Стандартная аббревиатура для Венской классификации;
(e) Стандарт ВОИС СТ.63 Рекомендации по содержанию и структуре бюллетеней товарных знаков;
(f) Стандарт ВОИС СТ.64 Рекомендуемые поисковые массивы для поиска по товарным знакам;
(g) Международная классификация товаров и услуг для международной регистрации знаков (Ниццкая классификация)
(h) Международная классификация изобразительных элементов знаков (Венская классификация)
(i) TM-XML (http://www.tm-xml.org/) версия 1.0: Спецификация, Словарь и Правила формирования;
(j) ISO/IEC 11179-5 Информационные технологии. Реестры метаданных (MDR). – Часть 5: Принципы именования и идентификации;
(k) ISO 3166-1 – Коды для представления названий стран и единиц их административно-территориального деления – Коды стран;
(l) ISO 639-1 – Коды для представления названий языков – Часть 1: Alpha2-код;
(m) ISO 4217 – Коды для представления валют и активов;
(n) ISO 8601 – Элементы даты и форматы обмена – Обмен информацией – Представление даты и времени;
(o) ISO/IEC 10646 – Информационные технологии – Универсальный многооктетный (многобайтовый) кодированный набор символов (UCS);
(p) 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)
(q) UN/CEFACT – Правила именования XML и Правила оформления, Версия 2.0;
(r) OASIS UBL Именование и Правила оформления;
(s) Запрос на комментарии (RFC) 2119 Оперативной группы по Интернет разработкам (IETF).
ТРЕБОВАНИЯ СТАНДАРТА
15. Основой данного стандарта является XML словарь СТ.66, приведенный в приложении 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 (трехбуквенные коды валют) ДОЛЖЕН использоваться для кодирования валют.
Символы
28. Настоящий стандарт рекомендует только таблицу Unicode. Представляется целесообразным добавить символьные сущности для тех символов, которые еще не указаны в Unicode. Использование этих сущностей требует создание глифов для представления, которых еще не существует. Более подробную информацию см. на http://www.w3.org/XML/Core/2002/10/charents-20021023
29. Сущности документов ДОЛЖНЫ включать первой строкой файла декларации XML.
(1) Замечание редактора: ebXML был опубликован в 1999 по инициативе Центра ООН по упрощению процедур торговли и электронным деловым операциям (UN/CEFACT) и Организация по продвижению стандартов структурированной информации (OASIS).
В данном стандарте рекомендуется только 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(Представление объекта)
-
GoodsServicesDescription: GoodsServices(Класс объекта) + Description(Свойство объекта) + Text(Представление объекта, опущено)
-
FilingDate: Mark(Класс объекта, опущено) + FilingDate(Свойство объекта)+ Date(Представление объекта, опущено)
45. Имена элементов, атрибутов и типов ДОЛЖНЫ быть уникальны. Именам СЛЕДУЕТ быть краткими и НЕ СЛЕДУЕТ содержать последовательных избыточных слов, также они ДОЛЖНЫ быть самоописывающими и по возможности хорошо структурированными.
46. Имена элементов, атрибутов и типов как и все их компоненты ДОЛЖНЫ быть в единственном числе, если сама концепция не является множественной. Например, GoodsServices, TotalMarkSeries
47. Имена элементов, атрибутов и типов ДОЛЖНЫ содержать только существительные, прилагательные и глаголы в основной форме. Такие слова как “and (союз)”, “of (предлог)”, “the (артикль)” ДОЛЖНЫ удаляться, кроме тех случаев, когда это удаление делает имя вводящим в заблуждение. Например, GoodsServices (Товары и услуги), DocumentSizeInByte (Размер документа в байтах)
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) следовать шестикомпонентному правилу именования. Шестикомпонентное правило именования проиллюстрировано ниже
(Таблицу смотрите во вложенном файле)
|
|
