Язык XML был изобретен в 1996 году. Едва он успел появиться, как возможности его применения уже начали понимать неправильно, и для тех целей, к которым его пытались адаптировать, он был не лучшим выбором.
Не будет преувеличением сказать, что подавляющее большинство схем XML, которые мне доводилось видеть, представляли собой нецелесообразное или неправильное использование XML. Более того, такое применение XML свидетельствовало о фундаментальном непонимании того, чем прежде всего является XML.
XML — это язык разметки. Это не формат данных. В большинстве схем XML это разграничение явно не учитывали, путая XML с форматом данных, что в итоге означало ошибку в самом выборе XML, поскольку на самом деле нужен был именно формат данных.
Если не вдаваться в детали, XML лучше всего подходит для аннотирования блоков текста со структурой и метаданными. Если вашей главной задачей не является работа с блоком текста, выбор XML вряд ли будет оправдан.
С этой точки зрения существует простой способ проверить, насколько хорошо сделана схема XML. Возьмем для примера документ в предполагаемой схеме и удалим из него все теги и атрибуты. Если в том, что осталось, нет смысла (или если осталась пустая строка), то либо ваша схема построена неправильно, либо вам просто не стоило применять XML.
Далее я приведу несколько наиболее часто встречающихся примеров неправильно построенных схем.
<roоt>
<item name="name" value="John" />
<item name="city" value="London" />
</roоt>Здесь мы видим пример необоснованной и странной (хоть и весьма распространенной) попытки выразить языком XML простой словарь «ключ-значение». Если удалить все теги и атрибуты, останется пустая строка. По существу данный документ представляет собой, как бы абсурдно это ни звучало, семантическую аннотацию пустой строки.
<root name="John" city="London" />Что еще хуже, у нас здесь не просто семантическая аннотация пустой строки как экстравагантный способ выражения словаря — на этот раз «словарь» напрямую закодирован в виде атрибутов корневого элемента. Из-за этого заданный набор имен атрибутов на элементе становится неопределенным и динамическим. Более того, отсюда видно, что все, что на самом деле хотел выразить автор, — это простой синтаксис «ключ-значение», но вместо этого он принял абсолютно странное решение применить XML, принудительно задавая использование одиночного пустого элемента просто в качестве префикса для использования синтаксиса атрибутов. И такие схемы попадаются мне очень часто.
<roоt>
<item key="name">John</item>
<item key="city">London</item>
</roоt>Это уже кое-что получше, но теперь ключи по какой-то причине являются метаданными, а значения — нет. Весьма странный взгляд на словари. Если удалить все теги и атрибуты, будет потеряна половина информации.
Правильное выражение словаря в XML будет выглядеть приблизительно так:
<roоt>
<item>
<key>Name</key>
<value>John</value>
</item>
<item>
<key>City</key>
<value>London</value>
</item>
</roоt>Но если люди приняли странное решение применять XML как формат данных и затем с помощью него упорядочивать словарь, то они должны понимать, что то, что они делают неуместно и не удобно. Еще часто проектировщики ошибочно выбирают XML для создания своих приложений. Но еще чаще они усугубляют ситуацию бессмысленным применением XML в одной из описанных выше форм, игнорируя тот факт, что XML для этого просто не подходит.
Самая худшая схема XML? Кстати, приз за самую худшую схему XML, которую мне доводилось видеть, получает формат файла конфигурации автоматического выделения ресурсов для телефонов IP-телефонии Polycom. Такие файлы требуют загрузки XML-файлов запроса по TFTP, которые… В общем, вот отрывок из одного такого файла:
<softkey
softkey.feature.directories="0"
softkey.feature.buddies="0"
softkey.feature.forward="0"
softkey.feature.meetnow="0"
softkey.feature.redial="1"
softkey.feature.search="1"
softkey.1.enable="1"
softkey.1.use.idle="1"
softkey.1.label="Foo"
softkey.1.insert="1"
softkey.1.action="..."
softkey.2.enable="1"
softkey.2.use.idle="1"
softkey.2.label="Bar"
softkey.2.insert="2"
softkey.2.action="..." />Это не чья-то неудачная шутка. И это не моя выдумка:
- элементы просто используются как префикс для прикрепления атрибутов, которые сами по себе имеют иерархические имена.
- Если нужно приписать значения нескольким экземплярам записи определенного вида, для этого необходимо использовать имена атрибутов, в которых есть индексы.
- Кроме этого, атрибуты, начинающиеся с
softkey., нужно помещать на элементы<softkey/>, атрибуты, начинающиеся сfeature., нужно помещать на элементы<feature/>и т. д., несмотря на то, что это выглядит совершенно излишним и на первый взгляд бессмысленным.
- И, наконец, если вы надеялись, что первый компонент имени атрибута всегда совпадает с именем элемента — ничего подобного! Например, атрибуты
up.должны прикрепляться к<userpreferences/>. Порядок прикрепления имен атрибутов к элементам — произвольный, причем практически полностью.
Документы или данные. Время от времени кто-то делает абсолютно странные вещи, пытаясь сравнивать XML и JSON, — и тем самым показывая, что не понимает ни того, ни другого. XML — это язык разметки документов. JSON же представляет собой формат структурированных данных, так что сравнивать их друг с другом — все равно что пытаться сравнить теплое с мягким.
Разобраться в этом поможет понятие разницы между документами и данными. В качестве аналога XML можно условно взять машиночитаемый документ. Хоть он и предназначен для считывания машиной, метафорически он относится к документам, и с этой точки зрения фактически является сопоставимым с документами формата PDF, которые чаще всего не являются машиночитаемыми.
К примеру, в XML имеет значение порядок элементов. А в JSON порядок следования пар «ключ-значение» внутри объектов не имеет смысла и не определен. Если вы хотите получить неупорядоченный словарь из пар «ключ-значение», фактический порядок, в котором следуют элементы в этом файле, не имеет значения. Но вы можете сформировать из этих данных много разных документов, поскольку в документе есть определенный порядок. Метафорически это аналог документа на бумаге, хоть он и не имеет физических размеров в отличие от распечатки или файла PDF.
В моем примере правильного представления словаря на языке XML показан порядок следования элементов в словаре, в отличие от представления на языке JSON. Я не могу игнорировать этот порядок: такая линейность изначально свойственна модели документов и формату XML. Кто-то при интерпретации этого XML-документа может решить проигнорировать порядок, но спорить по этому поводу бессмысленно, поскольку данный вопрос выходит за рамки обсуждения собственно формата. Более того, если сделать документ просматриваемым в браузере, прикрепив к нему каскадную таблицу стилей, можно будет увидеть, что элементы словаря следуют в определенном порядке, и ни в каком другом.
Другими словами, словарь (фрагмент структурированных данных) может быть преобразован в n различных возможных документов (в формате XML, PDF, на бумаге и т. п.), где n — количество возможных комбинаций элементов в словаре, и это мы еще не учли другие возможные переменные.
Вместе с тем из этого также следует, что если вы хотите передать одни только данные, то использовать для этого машиночитаемый документ будет не эффективно. В нем используется модель, которая в этом случае лишняя, она будет только мешать. К тому же, для того чтобы извлечь исходные данные, необходимо будет написать программу. Вряд ли есть смысл использовать XML для чего-то такого, что на определенном этапе не будет форматироваться в виде документа (скажем, с помощью CSS или XSLT, либо и того, и другого), поскольку это главная (если не единственная) причина для того, чтобы придерживаться модели документа.
Более того, поскольку в XML нет понятия чисел (или булевых выражений, либо других типов данных), все представленные в этом формате числа считаются лишь дополнительным текстом. Для извлечения данных должна быть известна схема и ее связь с соответствующими выражаемыми данными. Также необходимо знать, когда исходя из контекста тот или иной элемент текста представляет собой число, и его следует преобразовывать в число, и т. д.
Таким образом, процесс извлечения данных из документов XML не так уж сильно отличается от процесса распознавания отсканированных документов, содержащих, например, таблицы, образующие множество страниц численных данных. Да, сделать это в принципе возможно, но это не самый оптимальный путь, — разве что в крайнем случае, когда совсем нет других вариантов. Разумным решением будет просто найти цифровую копию оригинальных данных, не заложенных в модель документа, в которой данные объединены с их конкретным текстовым представлением.
При этом меня совсем не удивляет, что XML популярен в бизнесе. Причина этого именно в том, что формат документов (на бумаге) понятен и привычен для бизнеса, и там хотят продолжать пользоваться знакомой и понятной моделью. По той же самой причине в бизнесе слишком часто используют документы в PDF вместо более удобных для машинной обработки форматов — потому что они по-прежнему привязаны к понятию печатной страницы с определенным физическим размером. Это касается даже тех документов, которые вряд ли когда-нибудь будут распечатываться (например, PDF-файл документации реестра из 8000 страниц). С этой точки зрения использование XML в бизнесе по сути — проявление скевоморфизма. Людям понятна метафорическая идея печатной страницы ограниченного размера, и они понимают, как создавать бизнес-процессы на основе печатных документов. Если это ваш ориентир, документы без ограниченного физического размера, являющиеся машиночитаемыми — документы XML — представляют собой инновацию, являясь при этом знакомым и комфортным аналогом документа. Что не мешает им оставаться неверным и излишне скевоморфичным способом представления данных.
На сегодняшний день единственными известными мне схемами XML, которые я действительно могу назвать правильным применением этого формата, являются XHTML и DocBook.
Комментарии (82)
vintage
12.11.2019 12:22+3Господи, сколько же глупостей..
XML — это язык разметки. Это не формат данных.
Любой язык разметки — это частный случай формата данных. По определению. Которое вы поленились найти.
XML лучше всего подходит для аннотирования блоков текста со структурой и метаданными
Из чего не следует, что для чего-то отличного от аннотирования он не подходит. Аннотации — возможность, которой можно пользоваться, а можно (внезапно!) и не пользоваться. Всё зависит от конкретного основанного на этом формате (XML) языка (XHTML, SVG, MATHML, XSLT).
В JSON же такой возможности нет. Там даже нет возможности адекватно записать многострочный текст.
в отличие от представления на языке JSON. Я не могу игнорировать этот порядок: такая линейность изначально свойственна модели документов и формату XML. Кто-то при интерпретации этого XML-документа может решить проигнорировать порядок
В качестве упражения предлагаю вам записать в JSON обычное неупорядоченное множество. Массив тут явно не подойдёт, ведь там (о, боже!) линейность!
Более того, поскольку в XML нет понятия чисел (или булевых выражений, либо других типов данных), все представленные в этом формате числа считаются лишь дополнительным текстом. Для извлечения данных должна быть известна схема и ее связь с соответствующими выражаемыми данными. Также необходимо знать, когда исходя из контекста тот или иной элемент текста представляет собой число, и его следует преобразовывать в число, и т. д.
А DateTime, RegExp, ComplexNumber, BigInt, Decimal и прочие весёлые типы данных в JSON уже завезли? Схема данных и интерпретация уже не нужна?
StanEgo
12.11.2019 15:09Любой язык разметки — это частный случай формата данных. По определению. Которое вы поленились найти.
Где можно найти это определение? Если XML — это формат данных, то что тогда такое DTD? XML Schema? Зачем ими специфицировать формат данных, это же оксюморон? Или этот текст, который я пишу. Вполне себе SGML, каков его формат? А если я внезапно скажу, что LaTex или MDX? Имхо, не надо ничего выдумывать, Хомский это давно уже сделал.
Тот странный случай, когда хочется встать плечом к плечу с защитником XML,… но он пытается отнять у маркапов главное преимущество)) Структура документа эволюционирующая от условно никакой в текстах на натуральном языке до строго формальной (и вот здесь здравствуй формат данных), причем для различных агентов одновременно. Собственно в https://tei-c.org/ мы так и делали. Если к этому добавить всю экосистему XML (XPath, XSLT, XLink, XQuery, ...), то присоединюсь к тезису, что в JSON ещё очень многое "не завезли". И статья это правильно подчеркивает, показывая что область применения XML намного шире, не ограничена одним только рынком (де)сериализаторов. Например, я могу с легкостью представить себе эволюцию технического задания от простого текста с постепенной формализацией ER, MathML, форм и т.п. JSON я здесь не вижу никак.
ИИ-хайп бы во времена пика XML, да поддержку Semantic Web от того же Гугла.
vintage
12.11.2019 15:17Если XML — это формат данных, то что тогда такое DTD? XML Schema?
Форматы данных образуют иерархию. Схемы позволяют описывать подформаты.
Michailmi
12.11.2019 15:30RE: Господи, сколько же глупостей…
XML — это язык разметки. Это не формат данных.
Любой язык разметки — это частный случай формата данных. По определению.
Которое вы поленились найти
Нет. язык (XML) — НЕ частный случай формата данных. Наоборот. Какой-нибудь уникальный формат данных, который одинаково — определенно понимают только определенные (не все) источник и приемник — это частный случай языка. Схема XSD возможно = частный случай языка. Об этом (мне кажется верно) говорит статья. В смысле если уж хотите из XML делать формат данных, не надо так криво.
babylon
12.11.2019 21:47-3XML формат данных в том смысле, что данные пишутся и читаются по определенным формализованным правилам. JSON лучше, а mol.tree ещё лучше. И если автор реализует treenet подобно jsonnet то я скажу что это самый лучший формат
Bedal
13.11.2019 14:24хех, есть такая штука, стандарт IEC-61970 и ещё 100500 стандартов. Про то, как именно данные укладывать именно в XML
maxzh83
12.11.2019 12:24С этой точки зрения существует простой способ проверить, насколько хорошо сделана схема XML. Возьмем для примера документ в предполагаемой схеме и удалим из него все теги и атрибуты. Если в том, что осталось, нет смысла (или если осталась пустая строка), то либо ваша схема построена неправильно, либо вам просто не стоило применять XML.
Много раз прочитал этот кусок и все равно ничего не понял. Зачем удалять все теги и атрибуты? Что таким образом мы хотим проверить? Почему нет смысла?Eldhenn
12.11.2019 12:26Потому что XML, по мнению автора — это аннотирование текста. Опустим газету в серную кислоту, в смысле, удалим все аннотации. Получился текст? Нет? Вот видите!
rshinov
13.11.2019 09:55Имеется ввиду совершенно другое:
<item key="name">John</item> <item key="city">London</item>
На выходе John London
<item> <key>Name</key> <value>John</value> </item> <item> <key>City</key> <value>London</value> </item>
Name John City London
В первом случае формат данных привязали к языковой конструкции XML, во втором же формат данных и данные лежат отдельно
maxzh83
13.11.2019 09:58А откуда правило, что все, что внутри тегов мы оставляем, а что внутри атрибутов — нет? В первом примере, если брать еще и атрибуты (которые по сути тоже данные), то получится
name John city Londonrshinov
13.11.2019 10:47В этом я с вами согласен. Вся эта специфика никак не влияет на гибкость конечного приложения. Возможно в каких то инструментах и есть ограничения, а может и просто вкусовщина
VolCh
13.11.2019 11:49Из спецификации https://www.w3.org/TR/xml/#syntax. Стартовые тэги относятся к разметке, а атрибуты их часть. Грубо говоря, данные внутри тегов, а теги, атрибуты и прочая разметка, описывают логическую структуру эти данных, чем эти данные являются.
В терминах более-менее мейнстримового ООП атрибуты — это не свойства объекта элемента, а аннотации к ним, средство привязать к размеченным по элементам данным какую-то дополнительную информацию, подсказывающую как обрабатывать эти данные в тех или иных ситуациях, как аннотации, описывающие как свойство сериализировать или как его маппить на СУБД.
Nemutaisama
13.11.2019 14:56Вот только тут мы сталкиваемся с проблемой. Если верить спецификации (и здравому смыслу) то корректный XML будет выглядеть так
<item> <name>John</name> <city>London</city> </item>
Но после чистки тегов смысл потеряется…
P.S. Что-то я во времени потерялся, там уже оказывается все обсудили ниже =\
Femistoklov
12.11.2019 16:02Автор пытается убедить нас, что теги и атрибуты — это для метаданных, а контент — для данных. В принципе, для разметки это как раз верно, но, как тут уже сказали, это не единственное применение.
VolCh
12.11.2019 19:46Видимо автор сильно различает назначение (целевое применение) и применение на практике. Тут шутки про молоток в руках, микроскоп, пушки и т. п.
White_Scorpion
12.11.2019 12:43Это не формат данных. В большинстве схем XML это разграничение явно не учитывали, путая XML с форматом данных, что в итоге означало ошибку в самом выборе XML, поскольку на самом деле нужен был именно формат данных.
В истории мира достаточно примеров того, как вещь, изобретаемая для выполнения определённых задач — в результате не менее успешно применяется для совершенно других.
Взять вот к примеру, изобретение "виагры", которая разрабатывалась как стимулятор сердечной деятельности, а увеличение потенции есть ен что иное как — побочный эффект, ставший в результате испытаний — основным и ключевым.
Здесь мы видим пример необоснованной и странной (хоть и весьма распространенной) попытки выразить языком XML простой словарь «ключ-значение».
Понятие "необоснованный" — в данном случае не что иное как субъективность. Потому что если нужный (разработчику/заказчику) результат достигнут — что это как не достаточная обоснованность?
scg
12.11.2019 12:59Это не чья-то неудачная шутка. И это не моя выдумка:
Как правило, такие вещи зависят не от фантазии авторов а от используемых языка/библиотеки. Например, в некоторых случаях атрибуты сами распаковываются в словарик, а из иерархии тэгов его нужно специально вытаскивать. Что касается вашего пример с худшей схемой XML, то скорее всего, это XML прикручивали к уже существующей функциональности, и проще оказалось сделать такую ужасную схему, чем писать запаковщик-распаковщик или менять внутренне представление данных.
ss-nopol
12.11.2019 13:19Более того, поскольку в XML нет понятия чисел (или булевых выражений, либо других типов данных), все представленные в этом формате числа считаются лишь дополнительным текстом. Для извлечения данных должна быть известна схема и ее связь с соответствующими выражаемыми данными. Также необходимо знать, когда исходя из контекста тот или иной элемент текста представляет собой число, и его следует преобразовывать в число, и т. д.
Всё есть в XML Schema
amarao
12.11.2019 13:27Пуристы спорят о том, какие скобки лучше — лисповые или xml'ные. Для стороннего наблюдателя оба варианта ужасны и неприятны для чтения.
VikingRock
12.11.2019 14:44Но если люди, принявшие странное решение применять XML как формат данных и затем с помощью него упорядочивать словарь.
Где конец фразы?
UnclShura
12.11.2019 15:47+1Более того, поскольку в XML нет понятия чисел
Это ложь. В XML есть понятия и чисел и типов данных и структуры внутри поля. Просто ими как и собственно XSD мало кто пользуется.
Ну и приводить JSON в качестве хорошего формата данных…sshikov
12.11.2019 19:37>Просто ими как и собственно XSD мало кто пользуется.
Ну это еще вопрос. При всем неудобстве XSD, альтернативы не сильно лучше. Особенно альтернативы вне мира XML. А мало или много — ну тут надо бы опрос провести, а не гадать.vintage
12.11.2019 19:55При всем неудобстве XSD, альтернативы не сильно лучше.
Можете развернуть эту мысль? Просто я планирую создать альтернативу лучше.
sshikov
12.11.2019 20:13ну если только чуть-чуть. Это обширная тема, не на абзац.
Все зависит от применения. Я думаю все прекрасно видят, что мир полон сервисами, которые вообще без всякой схемы живут. Плохо или хорошо — не знаю, но живут.
Альтернативы конечно есть, и они в каком-то смысле лучше — скажем, RelaxNG лучше XSD — но толку-то? Ну вот что с того, что RelaxNG позволяет описать в схеме, что вот тут вот бывает либо дочерний элемент, либо атрибут? Ну да, позволяет. Или скажем Schematron — позволяет практически писать произвольные валидации на XSLT/XPath. Усилия только при этом соответственно вырастут. Или теперь прикрутим это к WSDL, например — уже не так удобно стало.
Schematron лучше XSD? Наверное да — он позволяет описать правила, которые на XSD не реализуемы. Schematron хуже XSD? Тоже да — потому что из XSD мы можем сделать допустим web сервис (вкупе с WSDL), и Schematron тут как пятое колесо в телеге, он ничего уже практически не дает, мы не можем его валидации применить, чтобы сгенерировать из них код на каком-либо языке, который будет потреблять или генерировать XML. Ну или усилия затрачиваемые на это растут непропорционально профиту.
А ведь есть еще RDF/S, к примеру, или OWL — которые тоже в каком-то смысле альтернативы. Их много, если подсчитать — но никто из них не занял даже такого места, как XSD. Я не уверен, что им мало кто пользуется, но он уже и не повсеместно. Повсеместно он был в лучшем случае во времена JavaEE. Лет 10 назад.vintage
12.11.2019 20:46-2Вам похоже нужен целый декларативный язык программирования, а не просто схемы.
sshikov
12.11.2019 21:17Далеко не только мне. Есть куча применений, где и схема не нужна, но есть куча других применений, где уже XSD не тянет. Опишите например FixML (я видел и работал с его XSD, это что-то ужасное).
>просто схемы
Не, ну если вы хотите придумать альтернативу XSD, то как вы опишете хотя бы то, что можно в RelaxNG — вот в этом месте может быть атрибут ID, либо дочерний элемент ID? Это ведь тоже схема, причем вполне статическая.
Хотя я не имею ничего против декларативного языка, но как показывает практика, хотя бы условия в нем часто нужны (пример чисто условный, но пусть будет: в таком случае — атрибут, а вот в таком — элемент).
А если нужны условия — нужен язык для их записи. XML в качестве такого языка так себе. Тут как минимум нужен XPath, хотя бы. А уж как только мы туда втащили второй язык — так и пошло-поехало. Как вы валидации собираетесь описывать? Связи внутри документа? Вот на выходе и получается что-то типа Schematron.
fougasse
12.11.2019 21:55Расскажите, а что такого ужасного в FIXML DTD?
Схема как схема, всё спокойно парсится и валидируется.
Да, 5.0 стал явно сложнее, никто не спорит.sshikov
12.11.2019 22:14FIXML DTD я никогда не видел, а XSD ужасен.
>всё спокойно парсится и валидируется
Это для машины. Она вообще железная, это ее работа.
А для человека он неадекватно сложен, объемен (а точнее скажем прямо — толст). И без инструмента вообще непригоден для потребления. Можно конечно сказать, что это так и было задумано — что схему не нужно читать глазами, ее нужно скормить некоей IDE, которая нам покажет все в графической форме. Но ведь при этом все равно получается, что как какое нетривиальное правило нужно — так все равно XPath в руки, Schematron на шею, и вперед, кодить с песнями.vintage
12.11.2019 22:21А можете привести пример такого нетривиального правила?
sshikov
13.11.2019 15:05Ну если совсем просто, то XSD не позволяет записать правила, зависящие от других элементов схемы. Ну т.е., какой-то кусок документа может присутствовать — но только если в другом месте написано то-то и то-то. Это вполне типичная ситуация для объектной модели, которая совершенно не отражается в схеме.
fougasse
12.11.2019 22:59XSD таки, прошу прощения.
Зачем его человеку читать в "сыром виде"?
Адекватный редактор отлично решает проблемы навигации, а читнуть на досуге можно и докуметацию в более привычном виде.
- Он отлично обрабатывается несложными скриптами.
mayorovp
13.11.2019 07:09Глянул я эту "ужасную" схему… ну да, схема большая, без хорошей IDE разобраться в ней сложно (кстати, рекомендую Visual Studio). Но какие вы видите альтернативы? Без схемы-то тут разобраться было бы ещё сложнее!
sshikov
13.11.2019 14:59Я никаких. С самого начала написал, что они все к сожалению не сильно лучше. Вопрос не в том что без IDE никуда, а скорее в том что и при наличии многие вещи описать невозможно.
fougasse
13.11.2019 21:59Какие, например?
Из реальной жизни, пожалуйста.sshikov
13.11.2019 22:55Да я уже раза два ответил, наверное. Посмотрите живьем на тот же схематрон, например, где фактически есть правила на базе XPath — вот я хочу такие правила в схеме. Язык я хочу, с условиями, вычислениями на дереве, возможно с функциями и прочим. Потому что без него все эти правила все равно так или иначе реализуются в коде. На Java, или на чем вы там пишете свои сервисы и клиентов. И при этом реализуются дважды, потому что описать их в схеме нельзя. Схематрон — это хорошо, это правильное направление, мне кажется что некий набор XPath (каким-то образом скомбинированный) позволил бы выразить все то, что хочется от схемы.
Ну то есть, если спросить меня, как я вижу идеальный язык схем, то я бы сказал, что это что-то типа RDF/S (потому, что в отличие от XSD он легче расширяется), в котором к схеме, ее элементам или атрибутам, подвешены XPath выражения, задающие дополнительные ограничения.fougasse
13.11.2019 23:08Т.е. примера из того же FIXML и недостаточности его XSD для решения реальной задачи, а не обсуждения сферического языка схем, не будет.
Что не так с бизнес-логикой на основе xsd — непонятно. Можно, в конце концов, и код сгенерировать по схеме, работает отлично в реальности, а не на бумаге.sshikov
14.11.2019 11:23-1Если вы не понимаете, что код сгенерированный по XSD сильно ограничен — мне сложно как-то еще это объяснить.
Если скажем у вас в XSD есть какая-то бизнес логика (хотя бы уровня XPath) — то можете сами ее продемонстрировать? На мой взгляд ее там просто не бывает, ибо язык это примитивный.
sshikov
14.11.2019 19:32Я пожалуй поясню еще раз. Если вас устраивает XSD и его возможности — это не плохо и не хорошо. Это просто значит, что у вас другие потребности. Уговаривать вас, что вам нужны более мощные и сложные инструменты — совершенно бесполезное занятие, и я этим заниматься точно не стану.
У меня за примерно 15 лет работы с XML схематрон был нужен в каждом втором проекте — а у вас, судя по всему, это слово вообще никаких ассоциаций и эмоций не вызывает. Может у вас схемы более простые, например? Ну так это тоже не хорошо и не плохо — просто другие задачи.
maxwolf
15.11.2019 17:19Можно я помогу коллеге sshikov примером? Это, правда, не FIXML, хотя область смежная, огромных промышленных масштабов, и вовлечённых «сил и средств», но, в то же время, достаточно открытая, чтобы дать URL на конкретный пример. Есть такой стандарт финансовых сообщений ISO20022 — SWIFT собирается перевести на него ВСЕ международные платежи 2021 году. Обычная «платёжка» — это документ
pacs.008. Текущая его схема — уже восьмой версии (первую выпустили AFAIR больше десяти лет назад), занимает более 50K, и содержит всевозможные restrictionы в количестве. Так вот, к ней (на том же сайте) прилагается ещё более обширный документ Message Definition Report (MDR), вторая часть коего содержит, для каждого типа сообщений, помимо MessageDefinition Functionality, Structure, Message Building Blocks, — раздел Constraints, полностью посвящённый ограничениям, которые невозможно выразить языком схемы. Чтобы прям совсем конкретный пример: для pacs.008 правило «C7 ChargesInformationAndInstructedAmountRule If ChargesInformation is present, then InstructedAmount must be present.» — описывает обязательность одного элемента в зависимости от наличия другого.
piton_nsk
14.11.2019 11:52Язык я хочу, с условиями, вычислениями на дереве, возможно с функциями и прочим. Потому что без него все эти правила все равно так или иначе реализуются в коде.
На схеме легко и понятно реализовать простейшие правила, а вот что-то более-менее сложное это уже вопрос. Реализуете вы это на схеме вместо кода, не получится ли хуже в плане понятности и отладки?sshikov
14.11.2019 19:24>не получится ли хуже в плане понятности и отладки
Простой ответ — я не знаю. Это то, чего я хотел бы, но как это сделать — точно не знаю.
В принципе, я бы готов был чтобы этот код генерировался из схемы, в какой-то процедурный или ООП язык, но исходный его вариант хранился бы в схеме. Ну или представлял бы из себя скажем набор XPath (впрочем, это будет фактически схематрон, а он к сожалению, не отличается лаконичностью).
kolemik
12.11.2019 15:51после того, как я прочитал книжечку некого Кая, я всегда думал, что XML — это просто формат передачи входных параметров на исполнение XSL-трансформации… А оно вот как о казалось-то…
nmrulin
12.11.2019 22:09+4Я может быть не совсем понял статью, но
<roоt> <item name="name" value="John" /> <item name="city" value="London" /> </roоt>
короче, чем было до «исправления». При том, что для восприятия и человека(ну вдруг полезет в код) и машины оба варианта почти одинаковы.
w0den
13.11.2019 01:00+1Мне кажется, что в этом примере более подходящий вариант должен быть:
<roоt> <name>John</name> <city>London</city> </roоt>
ivan386
13.11.2019 01:11Я для себя открыл что можно и так:
<roоt> <name/>John <city/>London </roоt>
Короче и легче при ручном вводе.
White_Scorpion
13.11.2019 11:46<roоt> <name/>John <city/>London </roоt>
Это походу явное нарушение нотации XML. Там вроде как по стандарту — запрещено смешивание текста и тэгов.
ivan386
13.11.2019 12:07Стандартный древний XML парсер парсер браузера это кушает нормально. Текст в XSLT это отдельный тип узла text(). Когда смешиваются текст и теги внутри узла в нём возникает несколько текстовых узлов. Когда в узле только текст то соответственно он содержит один текстовый узел.
В других примерах что то не так со второй буквой o в слове root так что на https://xmlvalidation.com/ можете проверить текст ниже:
<root> <name/>John <city/>London </root>
У меня результат: No errors were found
VolCh
13.11.2019 12:51+1Нет, не нарушение, это называется Mixed Content в спецификации. Описание документа или схема могут такое использование запретить, но єто не запрет самого XML
Bronx
13.11.2019 01:22Если делать по науке, то должно быть вообще примерно так:
<root> <name>John</name> <city>London</city> </root>
где
root,nameиcity— типы данных.
255
12.11.2019 22:36+1Не могу согласиться с автором.
Во-1х, XML просто пригоден для отображения в виде текста. Поля внутри могут быть совершенно разные по типам.
Во-2х, как раз для текста есть множество других инструментов. А вот для «строгой статической типизации» передаваемых данных — только еще гораздо менее популярные, чем XML.
Тип в XML нельзя заменить совсем-совсем таким же, но иначе названным типом. Если разработчик XSD сказал, что tCustomer и tMerchant разные типы, то так оно и есть. Если бы он хотел сделать их взаимозаменяемыми, то присвоил бы Customer и Merchant тип tPerson.
Если схема изменится, то изменится и ее версия, и каждый разработчик должен будет прямо подтвердить, что новая версия поддерживается. Иначе XML по новой схеме будут игнорироваться.
Кроме того, типы в XML/XSD отлично задаются со строгими паттернами. Я могу задать почтовому адресу паттерн "^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+$", и любой реквест с адресом «вася@vasya:)» будет выкинут стандартной процедурой валидации. Мне не надо писать специальную проверку адресов, весь XML проверяется одной процедурой.
Из XSD схемы можно за пять минут сделать готовую форму для ее заполнения на базе Jaxe, с мгновенной проверкой валидности полей при вводе, поддержкой множественных элементов и ограничений на них. XSLT позволяют прикрепить к любому XML форму отображения для человекочитаемости.
Конечно, есть и многое, что XML/XSD не может. Он не предназначен заменить, например, блеклисты или защиту от инъекций. И это громоздкий формат, он не экономит биты. Но когда день простоя дороже лишнего терабайта данных, это просто хорошее универсальное решение.JustDont
13.11.2019 11:25+2Я могу задать почтовому адресу паттерн "^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+$"
Вы имели в виду —
(?:[a-z0-9!#$%&'*+/=?^_`{|}~-]+(?:\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*|"(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21\x23-\x5b\x5d-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])*")@(?:(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\.)+[a-z0-9](?:[a-z0-9-]*[a-z0-9])?|\[(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?|[a-z0-9-]*[a-z0-9]:(?:[\x01-\x08\x0b\x0c\x0e-\x1f\x21-\x5a\x53-\x7f]|\\[\x01-\x09\x0b\x0c\x0e-\x7f])+)\])?
К слову, это тоже не точная валидация.
sania
13.11.2019 18:15Где-то помню читал, что на валидации почтового ящика должно быть одно правило — наличие @
А основная валидация происходит открытием ссылки активации из почты.Zenitchik
13.11.2019 19:29-2Насколько я помню, после @ должен быть валидный домен. А что перед @ — на 100% проблемы почтового сервера, его предоставляющего.
klvov
12.11.2019 23:19+1При всей моей «любви» к XML, с которым вожусь года этак с 2000-го, только когда его у меня отобрали, и решили, что теперь работаем с JSON, только тогда я понял, чего лишился.
В статье, кстати, указаны примеры неправильного использования XML, где я полностью согласен, что это использование — неправильное. Словарь «ключ — значение» можно сделать гораздо проще без XML. И вот этот вот ужастный формат plist (использовался при программировании для iPhone) — тоже неправильное использование. И даже XSD и WSDL — где вроде бы уже технология применяется более адекватно — все равно это как-то использовать неудобно. XSLT — вот тут уже можно приводить аргументы за и против, потому что при всей своей синтаксической шумности этот шаблонизатор позволял решить любые задачи (совсем в крайнем случае можно было вызвать функцию на JS). А уж XPath — так это и вообще получился аналог SQL, декларативный язык для выборки данных из древовидных структур. Для JSON сейчас такого индустриального стандарта нет, в Postgres вроде что-то делают похожее, и еще есть jspath от Д. Филатова. Но от возможностей XPath это максимум 10% сейчас.
Я, наверное, считаю XML не языком разметки текста, а языком описания древовидных структур. То есть неким близким родственником LISP-а, с той разницей, что лиспы более заточены под описание AST-дерева, а XML под разметку текстовых (и гипертекстовых, вроде XHTML) документов. Или визуальных форм (в Delphi графические формы хранились в *.dfm-файлах, в которых фактически описывалась древовидная структура, содержащая отношения вложенности компонентов).
Bronx
13.11.2019 01:41Правильное выражение словаря в XML будет выглядеть приблизительно так:
Это "правильно" только для нетипизированного (т.е. невалидируемого) открытого словаря "строка-строка", который сам по себе зачастую является проявлением лени и ошибкой дизайна.
Я так и не понял, в чём принципиальное различие между "форматом данных" и "документом"? Дерево, представленное байтами, уложенными последовательно в памяти или в бинарнике — это "данные" или "документ в формате цепочки байтов"? По мне что байты, что текст — это лишь разные конкретные репрезентации одних и тех же абстрактных данных, т.е. любое физическое представление на каком-то накопителе — это "документ", который можно трансформировать в другое представление и получить другой "документ".
saboteur_kiev
13.11.2019 01:42На сегодняшний день единственными известными мне схемами XML, которые я действительно могу назвать правильным применением этого формата, являются XHTML и DocBook.
А какже FB2?
frkbvfnjh
13.11.2019 07:23Не стал читать до конца, т.к. не понимаю, почему тот или иной стандарт нельзя использовать не по назначению, если сам стандарт это позволяет. Так что убежден в том, что в таких случаях проблема не в том, кто этот стандарт использует не по назначению, а в самом стандарте. Да и что плохого в использовании стандарта не по назначению, если это позволяет достичь нужного результата? Если бы JSON изобрели раньше XML, то для обмена данными явно все пользовались бы JSON, а XML'ом бы пользовались по его прямому назначению. В пример можно поставить к примеру разработку прикладных решений на 1С — изначально не поддерживалась объектная работа с JSON и не было никаких инструментов для работы с JSON, разве что писать свои парсеры, поэтому все использовали для обмена данными XML, хотя согласен, что 99% процентов и не подозревали, что он для этого и не очень то предназначен, но другой адекватной альтернативы по быстрому накидать обмен не было, кроме того при обмене данными необходимо избавиться от избыточности данных и нужно что бы передаваемые данные весили как можно меньше, особенно в 1996 году, поэтому собственно и суют все в атрибуты, а не расписывают, всю красоту стандарта XML. Так что примеры «неудачных» XML представленных в начале статьи как раз и говорят о том, что представленные данные скорее всего и использовались для обмена, причем как вынужденная мера. Тоже самое, как мне кажется, касается и др. языков программирования. Думаете, когда люди «вкусили» JSON (и получили готовые инструменты работы с ним), кто-то еще хотел использовать XML для обмена данными? Больно то нужен кому-то это монстроидальный, не читабельный формат. Если сейчас где-то еще и есть обмен данными на XML, то только потому, что «работает – не трогай», и никто не будет тратить ресурсы на переделку, а тот, кто использует XML для обмена данными в новых проектах, то он либо не знает о JSON, либо конченных мазохист-извращенец! Может именно поэтому многие и считают XML «мраком», когда начинают использовать его для обмена данными, потому, что не очень-то он для этого и предназначен.
vintage
13.11.2019 08:00-1тот, кто использует XML для обмена данными в новых проектах, то он либо не знает о JSON, либо конченных мазохист-извращенец
tendium
13.11.2019 08:14TL;DR: Статья о том, как автору не нравится, что XML, как когда-то новая технология, изначально предназначенная для одного, внезапно оказалась удобной и для чего-то другого.
GavrilovArtem
13.11.2019 09:54И это же ещё не затронута тема SOAP и SOAP-сервисов — топ-банки с этим ещё будут жить долго...
vsb
13.11.2019 11:12JSON удобен, когда не хочется заморачиваться с подробным описанием структуры данных. Она обычно очевидна из примера. В случае XML это не совсем так. Для нормального маппинга необходима схема, написание и поддержание которой это отдельная задача. Кроме того нет однозначного и общепринятого отображения XML схемы на типовые структуры данных ЯП.
А так при желании и с XML-схемой можно заморочиться и с JSON-схемой можно. Тут они примерно равны по возможностям. Но по-быстрому проще и удобней сделать на JSON. Поэтому он и выиграл.
Кроме того JSON в целом проще для понимания. Разобраться в нюансах XML Schema это достаточно объёмная задача. Новые разработчики этого пугаются.
Tanner
13.11.2019 11:35Если ваш ЯП имеет гибкие, расширяемые, легко сериализуемые структуры данных, то вы просто пользуетесь ими. Но если система типов вашего ЯП такова, что проще описать структуру данных на чём угодно другом, то
a cat is fine tooпочему бы и не на XML?
Victor_koly
Но почему-то в старенькой игре Crysis к каждому файлу сейва идет файл .xml.
Ещё, ЕМНИП, ArcGIS что-то хранит в таких файлах. Может как-то конвертировтаь шейпы в XML можно.
trir
метаданные
да