Original:http://xfront.com/accelerating-adoption-of-XML-vocabularies/

Вы здесь: Главная > Что нового > Ускорение принятия XML-заметок

Ускорение принятия XML-заметок

Хотите ускорить принятие своего словаря XML? Один из способов состоит в том, чтобы заставить горилла 800 фунтов стерлингов заставить всех использовать ее. Но это скоро приведет к возмущению и восстанию. Лучший способ - создать то, что люди действительно захотят использовать, и не требует от них больших инвестиций во времени или денег и позволяет им немедленно начать взаимодействие. Вот как:

  1. Когда вы создаете словарь XML, укажите не только значение разметки, но и его поведение в приложениях, которые его обрабатывают.
  2. Укажите правила соответствия.
  3. Создайте тестовый набор.
  4. Создайте приложение, которое реализует поведение.
  5. Подтвердите применение приложения к набору тестов.
  6. Сделайте приложение доступным для всего мира.

В идеале, будут созданы несколько реализаций приложения (каждый из которых будет иметь такое же поведение, конечно!). Таким образом, пользователи могут выбирать реализацию на основе ее производительности или размера или того языка программирования, на котором она была реализована.

Это оно! Сделайте это, и ваш словарь XML можно быстро принять.

: Consider the XSLT vocabulary. Пример . Рассмотрим словарь XSLT. Спецификация XSLT указывает не только значение каждого элемента и атрибута, но и их поведение. Спецификация XSLT содержит правила соответствия. Существует набор тестов XSLT. Было создано приложение, называемое XSLT-процессором, которое реализует поведение, указанное в спецификации XSLT. На самом деле были созданы несколько реализаций приложения: Xalan, Saxon, Sableton и другие.

Позвольте мне подробнее рассказать о том, что я подразумеваю под «определением поведения». Рассмотрим снова XSLT. В спецификации XSLT указано, что элемент <xsl: for-each> идентифицирует коллекцию узлов. Это значение. В нем также говорится, что совместимое приложение должно проходить через каждый узел, идентифицированный атрибутом select (для каждого элемента есть атрибут select) и выполнять элементы внутри <xsl: for-each>. Это поведение. Таким образом, спецификация XSLT указывает, как приложение должно вести себя в элементе <xsl: for-each>. То же самое для всего словаря XSLT.

Спецификация XML Schema отлично справляется с определением поведения валидаторов XML Schema. Например, он указывает, что для объявления элемента в XML-схеме валидатор должен проверить, что документ экземпляра XML содержит правильное количество вхождений элемента, а его содержимое имеет правильный тип. Таким образом, он указывает, как валидатор должен вести себя в словаре XML Schema. Таким образом, чтобы «указать поведение» означает «описывать» этот элемент (или атрибут) в словаре, приложение должно сделать это, это и это ».

Ошибка, которую люди делают при создании словаря XML, заключается в том, что они не могут указать свое поведение. Они оставляют это до «мира», чтобы выяснить, каково должно быть поведение. Классическим примером этого является HTML. Разработчики браузеров должны были решить, каково должно быть поведение. У них были разные идеи о правильном поведении. Следствием этого было то, что IE, Firefox и другие браузеры вели себя по-другому. Прошло 10 лет, прежде чем они, наконец, пришли к единому пониманию поведения. Если бы спецификация HTML указывала на поведение, при условии соблюдения правил соответствия и набора тестов, то у нас было бы одинаковое поведение браузеров 10 лет назад.

Одна вещь, которую вы должны учитывать при определении поведения, такова: будет ли ваш XML-словарь загружаться в приложение как один XML-документ или как два XML-документа? (Или больше?) Давайте рассмотрим несколько примеров, чтобы понять, что я имею в виду:

  • Приложения браузера обрабатывают один документ (документ HTML)
  • Валидаторы XML Schema обрабатывают два документа (документ XML-схемы и XML-документ)
  • Процессоры XSLT обрабатывают два документа (документ XSLT и XML-документ)

В этих примерах приложениями являются браузер, средство проверки схемы XML и процессор XSLT. Эти приложения обрабатывают словарь XML. В зависимости от словаря XML приложение может потребовать один входной документ или два входных документа (или более).

Совместимость данных

Я часто слышал, как он сказал: «Для обеспечения совместимости данных каждое приложение должно интерпретировать / понимать словарь XML таким же образом».

Какой лучший способ обеспечить такую ​​же интерпретацию / понимание, чем использовать одно и то же приложение!

Используя одно и то же приложение, мы можем обеспечить идеальную совместимость данных. ПРИМЕЧАНИЕ. Когда я говорю «одно и то же приложение», я имею в виду набор реализаций. Таким образом, Xalan, Saxon и Sabletron - одно и то же приложение - все они XSLT-процессоры. Использование одного и того же приложения не означает, например, что каждый использует Xalan. Один человек может использовать Xalan, другой - саксонский и другой Sabletron. Это нормально; все они имеют одинаковое поведение; все они следуют правилам соответствия XSLT; все они проходят тестовый набор XSLT.

Вот пример, иллюстрирующий, как взаимодействие данных достигается путем совместного использования одного и того же приложения.

: Consider XSLT. Пример . Рассмотрим XSLT. Я могу создать XSLT-документ и запустить его на своем XSLT-процессоре. Я могу отправить вам документ XSLT и запустить его на вашем XSLT-процессоре. Мы получаем такое же поведение. Мы полностью согласны с тем, что означает элемент <xsl: for-each> и как он должен себя вести. То же самое для всех других элементов и атрибутов в словаре XSLT. Мы успешно взаимодействовали. Что это позволило? Ответ. Что обеспечило взаимодействие, так это то, что мы используем одно и то же приложение. (Опять же, я должен подчеркнуть, что это не означает, что мы используем одну и ту же реализацию приложения, вы можете использовать Xalan, и я могу использовать Saxon, это нормально, это оба XSLT-процессора.)

Я могу создать второй документ XSLT и отправить его вам. Опять же, у нас отличная функциональная совместимость. И третий документ XSLT. И так далее. Приложение XSLT-процессора облегчает создание, обмен и выполнение бесконечных различных XSLT-преобразований с идеальным пониманием / совместимостью.

резюмировать

Вот основные моменты:

  1. Когда вы создаете словарь XML, укажите поведение словаря XML. Укажите требования к соответствию. Создайте тестовый набор. Реализация соответствующих приложений, каждый из которых имеет одинаковое поведение (реализации могут отличаться по размеру, производительности, языку программирования и т. Д.). Все используют реализации.
  2. Совместимость данных не достигается благодаря совместному пониманию словаря XML. Интеграция данных достигается за счет совместного использования приложения словаря XML.
  3. Создание словаря XML без указания его поведения - плохая идея. Это рецепт отсроченной совместимости данных в лучшем случае, неудачная совместимость данных в худшем случае.

Перевод

Шерали Ниязова перевела эту статью на узбекский язык: http://eduworksdb.com/accelerating-adoption-of-xml-vocabularies/

Артур Вебер перевел эту статью на португальский язык: Перевод на португальский язык для https://www.homeyou.com/~edu/

Петра Влашич перевела эту статью на македонский язык: http://makescience.net/accelerating-adoption-of-xml-vocabularies/

Петра Влашич перевела эту статью боснийцам: http://petravlasic.net/accelerating-adoption-of-xml-vocabularies/

Последнее обновление: 7 декабря 2017 г.