Комментарии 95
XML — это язык разметки. Это не формат данных.
Но почему-то в старенькой игре Crysis к каждому файлу сейва идет файл .xml.
Ещё, ЕМНИП, ArcGIS что-то хранит в таких файлах. Может как-то конвертировтаь шейпы в XML можно.
Господи, сколько же глупостей..
XML — это язык разметки. Это не формат данных.
Любой язык разметки — это частный случай формата данных. По определению. Которое вы поленились найти.
XML лучше всего подходит для аннотирования блоков текста со структурой и метаданными
Из чего не следует, что для чего-то отличного от аннотирования он не подходит. Аннотации — возможность, которой можно пользоваться, а можно (внезапно!) и не пользоваться. Всё зависит от конкретного основанного на этом формате (XML) языка (XHTML, SVG, MATHML, XSLT).
В JSON же такой возможности нет. Там даже нет возможности адекватно записать многострочный текст.
в отличие от представления на языке JSON. Я не могу игнорировать этот порядок: такая линейность изначально свойственна модели документов и формату XML. Кто-то при интерпретации этого XML-документа может решить проигнорировать порядок
В качестве упражения предлагаю вам записать в JSON обычное неупорядоченное множество. Массив тут явно не подойдёт, ведь там (о, боже!) линейность!
Более того, поскольку в XML нет понятия чисел (или булевых выражений, либо других типов данных), все представленные в этом формате числа считаются лишь дополнительным текстом. Для извлечения данных должна быть известна схема и ее связь с соответствующими выражаемыми данными. Также необходимо знать, когда исходя из контекста тот или иной элемент текста представляет собой число, и его следует преобразовывать в число, и т. д.
А DateTime, RegExp, ComplexNumber, BigInt, Decimal и прочие весёлые типы данных в JSON уже завезли? Схема данных и интерпретация уже не нужна?
Любой язык разметки — это частный случай формата данных. По определению. Которое вы поленились найти.
Где можно найти это определение? Если 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 от того же Гугла.
XML — это язык разметки. Это не формат данных.
Любой язык разметки — это частный случай формата данных. По определению.
Которое вы поленились найти
Нет. язык (XML) — НЕ частный случай формата данных. Наоборот. Какой-нибудь уникальный формат данных, который одинаково — определенно понимают только определенные (не все) источник и приемник — это частный случай языка. Схема XSD возможно = частный случай языка. Об этом (мне кажется верно) говорит статья. В смысле если уж хотите из XML делать формат данных, не надо так криво.
С этой точки зрения существует простой способ проверить, насколько хорошо сделана схема XML. Возьмем для примера документ в предполагаемой схеме и удалим из него все теги и атрибуты. Если в том, что осталось, нет смысла (или если осталась пустая строка), то либо ваша схема построена неправильно, либо вам просто не стоило применять XML.
Много раз прочитал этот кусок и все равно ничего не понял. Зачем удалять все теги и атрибуты? Что таким образом мы хотим проверить? Почему нет смысла?
Если в том, что осталось, нет смысла (или если осталась пустая строка)
то статья так себе.
Имеется ввиду совершенно другое:
<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, во втором же формат данных и данные лежат отдельно
name John city London
В этом я с вами согласен. Вся эта специфика никак не влияет на гибкость конечного приложения. Возможно в каких то инструментах и есть ограничения, а может и просто вкусовщина
Из спецификации https://www.w3.org/TR/xml/#syntax. Стартовые тэги относятся к разметке, а атрибуты их часть. Грубо говоря, данные внутри тегов, а теги, атрибуты и прочая разметка, описывают логическую структуру эти данных, чем эти данные являются.
В терминах более-менее мейнстримового ООП атрибуты — это не свойства объекта элемента, а аннотации к ним, средство привязать к размеченным по элементам данным какую-то дополнительную информацию, подсказывающую как обрабатывать эти данные в тех или иных ситуациях, как аннотации, описывающие как свойство сериализировать или как его маппить на СУБД.
Это не формат данных. В большинстве схем XML это разграничение явно не учитывали, путая XML с форматом данных, что в итоге означало ошибку в самом выборе XML, поскольку на самом деле нужен был именно формат данных.
В истории мира достаточно примеров того, как вещь, изобретаемая для выполнения определённых задач — в результате не менее успешно применяется для совершенно других.
Взять вот к примеру, изобретение "виагры", которая разрабатывалась как стимулятор сердечной деятельности, а увеличение потенции есть ен что иное как — побочный эффект, ставший в результате испытаний — основным и ключевым.
Здесь мы видим пример необоснованной и странной (хоть и весьма распространенной) попытки выразить языком XML простой словарь «ключ-значение».
Понятие "необоснованный" — в данном случае не что иное как субъективность. Потому что если нужный (разработчику/заказчику) результат достигнут — что это как не достаточная обоснованность?
Более того, поскольку в XML нет понятия чисел (или булевых выражений, либо других типов данных), все представленные в этом формате числа считаются лишь дополнительным текстом. Для извлечения данных должна быть известна схема и ее связь с соответствующими выражаемыми данными. Также необходимо знать, когда исходя из контекста тот или иной элемент текста представляет собой число, и его следует преобразовывать в число, и т. д.
Всё есть в XML Schema
Пуристы спорят о том, какие скобки лучше — лисповые или xml'ные. Для стороннего наблюдателя оба варианта ужасны и неприятны для чтения.
Но если люди, принявшие странное решение применять XML как формат данных и затем с помощью него упорядочивать словарь.
Где конец фразы?
Более того, поскольку в XML нет понятия чисел
Это ложь. В XML есть понятия и чисел и типов данных и структуры внутри поля. Просто ими как и собственно XSD мало кто пользуется.
Ну и приводить JSON в качестве хорошего формата данных…
Ну это еще вопрос. При всем неудобстве XSD, альтернативы не сильно лучше. Особенно альтернативы вне мира XML. А мало или много — ну тут надо бы опрос провести, а не гадать.
При всем неудобстве XSD, альтернативы не сильно лучше.
Можете развернуть эту мысль? Просто я планирую создать альтернативу лучше.
Все зависит от применения. Я думаю все прекрасно видят, что мир полон сервисами, которые вообще без всякой схемы живут. Плохо или хорошо — не знаю, но живут.
Альтернативы конечно есть, и они в каком-то смысле лучше — скажем, RelaxNG лучше XSD — но толку-то? Ну вот что с того, что RelaxNG позволяет описать в схеме, что вот тут вот бывает либо дочерний элемент, либо атрибут? Ну да, позволяет. Или скажем Schematron — позволяет практически писать произвольные валидации на XSLT/XPath. Усилия только при этом соответственно вырастут. Или теперь прикрутим это к WSDL, например — уже не так удобно стало.
Schematron лучше XSD? Наверное да — он позволяет описать правила, которые на XSD не реализуемы. Schematron хуже XSD? Тоже да — потому что из XSD мы можем сделать допустим web сервис (вкупе с WSDL), и Schematron тут как пятое колесо в телеге, он ничего уже практически не дает, мы не можем его валидации применить, чтобы сгенерировать из них код на каком-либо языке, который будет потреблять или генерировать XML. Ну или усилия затрачиваемые на это растут непропорционально профиту.
А ведь есть еще RDF/S, к примеру, или OWL — которые тоже в каком-то смысле альтернативы. Их много, если подсчитать — но никто из них не занял даже такого места, как XSD. Я не уверен, что им мало кто пользуется, но он уже и не повсеместно. Повсеместно он был в лучшем случае во времена JavaEE. Лет 10 назад.
Вам похоже нужен целый декларативный язык программирования, а не просто схемы.
>просто схемы
Не, ну если вы хотите придумать альтернативу XSD, то как вы опишете хотя бы то, что можно в RelaxNG — вот в этом месте может быть атрибут ID, либо дочерний элемент ID? Это ведь тоже схема, причем вполне статическая.
Хотя я не имею ничего против декларативного языка, но как показывает практика, хотя бы условия в нем часто нужны (пример чисто условный, но пусть будет: в таком случае — атрибут, а вот в таком — элемент).
А если нужны условия — нужен язык для их записи. XML в качестве такого языка так себе. Тут как минимум нужен XPath, хотя бы. А уж как только мы туда втащили второй язык — так и пошло-поехало. Как вы валидации собираетесь описывать? Связи внутри документа? Вот на выходе и получается что-то типа Schematron.
Расскажите, а что такого ужасного в FIXML DTD?
Схема как схема, всё спокойно парсится и валидируется.
Да, 5.0 стал явно сложнее, никто не спорит.
>всё спокойно парсится и валидируется
Это для машины. Она вообще железная, это ее работа.
А для человека он неадекватно сложен, объемен (а точнее скажем прямо — толст). И без инструмента вообще непригоден для потребления. Можно конечно сказать, что это так и было задумано — что схему не нужно читать глазами, ее нужно скормить некоей IDE, которая нам покажет все в графической форме. Но ведь при этом все равно получается, что как какое нетривиальное правило нужно — так все равно XPath в руки, Schematron на шею, и вперед, кодить с песнями.
А можете привести пример такого нетривиального правила?
XSD таки, прошу прощения.
Зачем его человеку читать в "сыром виде"?
Адекватный редактор отлично решает проблемы навигации, а читнуть на досуге можно и докуметацию в более привычном виде.
- Он отлично обрабатывается несложными скриптами.
Глянул я эту "ужасную" схему… ну да, схема большая, без хорошей IDE разобраться в ней сложно (кстати, рекомендую Visual Studio). Но какие вы видите альтернативы? Без схемы-то тут разобраться было бы ещё сложнее!
Какие, например?
Из реальной жизни, пожалуйста.
Ну то есть, если спросить меня, как я вижу идеальный язык схем, то я бы сказал, что это что-то типа RDF/S (потому, что в отличие от XSD он легче расширяется), в котором к схеме, ее элементам или атрибутам, подвешены XPath выражения, задающие дополнительные ограничения.
Т.е. примера из того же FIXML и недостаточности его XSD для решения реальной задачи, а не обсуждения сферического языка схем, не будет.
Что не так с бизнес-логикой на основе xsd — непонятно. Можно, в конце концов, и код сгенерировать по схеме, работает отлично в реальности, а не на бумаге.
Если скажем у вас в XSD есть какая-то бизнес логика (хотя бы уровня XPath) — то можете сами ее продемонстрировать? На мой взгляд ее там просто не бывает, ибо язык это примитивный.
У меня за примерно 15 лет работы с XML схематрон был нужен в каждом втором проекте — а у вас, судя по всему, это слово вообще никаких ассоциаций и эмоций не вызывает. Может у вас схемы более простые, например? Ну так это тоже не хорошо и не плохо — просто другие задачи.
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.» — описывает обязательность одного элемента в зависимости от наличия другого.
Язык я хочу, с условиями, вычислениями на дереве, возможно с функциями и прочим. Потому что без него все эти правила все равно так или иначе реализуются в коде.
На схеме легко и понятно реализовать простейшие правила, а вот что-то более-менее сложное это уже вопрос. Реализуете вы это на схеме вместо кода, не получится ли хуже в плане понятности и отладки?
Простой ответ — я не знаю. Это то, чего я хотел бы, но как это сделать — точно не знаю.
В принципе, я бы готов был чтобы этот код генерировался из схемы, в какой-то процедурный или ООП язык, но исходный его вариант хранился бы в схеме. Ну или представлял бы из себя скажем набор XPath (впрочем, это будет фактически схематрон, а он к сожалению, не отличается лаконичностью).
А то, что используется в офисных форматах, docx, например, разве не разметка?
<roоt>
<item name="name" value="John" />
<item name="city" value="London" />
</roоt>
короче, чем было до «исправления». При том, что для восприятия и человека(ну вдруг полезет в код) и машины оба варианта почти одинаковы.
<roоt>
<name>John</name>
<city>London</city>
</roоt>
Я для себя открыл что можно и так:
<roоt>
<name/>John
<city/>London
</roоt>Короче и легче при ручном вводе.
Как такое парсить? 0_о
Если хочется не дублировать слова name и city, то можно так
<root>
<item name="John" city="London"/>
</root>
<roоt>
<name/>John
<city/>London
</roоt>Это походу явное нарушение нотации XML. Там вроде как по стандарту — запрещено смешивание текста и тэгов.
Стандартный древний XML парсер парсер браузера это кушает нормально. Текст в XSLT это отдельный тип узла text(). Когда смешиваются текст и теги внутри узла в нём возникает несколько текстовых узлов. Когда в узле только текст то соответственно он содержит один текстовый узел.
В других примерах что то не так со второй буквой o в слове root так что на https://xmlvalidation.com/ можете проверить текст ниже:
<root>
<name/>John
<city/>London
</root>У меня результат: No errors were found
Нет, не нарушение, это называется Mixed Content в спецификации. Описание документа или схема могут такое использование запретить, но єто не запрет самого XML
Если делать по науке, то должно быть вообще примерно так:
<root>
<name>John</name>
<city>London</city>
</root>где root, name и city — типы данных.
Во-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 не может. Он не предназначен заменить, например, блеклисты или защиту от инъекций. И это громоздкий формат, он не экономит биты. Но когда день простоя дороже лишнего терабайта данных, это просто хорошее универсальное решение.
Я могу задать почтовому адресу паттерн "^[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])+)\])
?К слову, это тоже не точная валидация.
В статье, кстати, указаны примеры неправильного использования XML, где я полностью согласен, что это использование — неправильное. Словарь «ключ — значение» можно сделать гораздо проще без XML. И вот этот вот ужастный формат plist (использовался при программировании для iPhone) — тоже неправильное использование. И даже XSD и WSDL — где вроде бы уже технология применяется более адекватно — все равно это как-то использовать неудобно. XSLT — вот тут уже можно приводить аргументы за и против, потому что при всей своей синтаксической шумности этот шаблонизатор позволял решить любые задачи (совсем в крайнем случае можно было вызвать функцию на JS). А уж XPath — так это и вообще получился аналог SQL, декларативный язык для выборки данных из древовидных структур. Для JSON сейчас такого индустриального стандарта нет, в Postgres вроде что-то делают похожее, и еще есть jspath от Д. Филатова. Но от возможностей XPath это максимум 10% сейчас.
Я, наверное, считаю XML не языком разметки текста, а языком описания древовидных структур. То есть неким близким родственником LISP-а, с той разницей, что лиспы более заточены под описание AST-дерева, а XML под разметку текстовых (и гипертекстовых, вроде XHTML) документов. Или визуальных форм (в Delphi графические формы хранились в *.dfm-файлах, в которых фактически описывалась древовидная структура, содержащая отношения вложенности компонентов).
Правильное выражение словаря в XML будет выглядеть приблизительно так:
Это "правильно" только для нетипизированного (т.е. невалидируемого) открытого словаря "строка-строка", который сам по себе зачастую является проявлением лени и ошибкой дизайна.
Я так и не понял, в чём принципиальное различие между "форматом данных" и "документом"? Дерево, представленное байтами, уложенными последовательно в памяти или в бинарнике — это "данные" или "документ в формате цепочки байтов"? По мне что байты, что текст — это лишь разные конкретные репрезентации одних и тех же абстрактных данных, т.е. любое физическое представление на каком-то накопителе — это "документ", который можно трансформировать в другое представление и получить другой "документ".
На сегодняшний день единственными известными мне схемами XML, которые я действительно могу назвать правильным применением этого формата, являются XHTML и DocBook.
А какже FB2?
тот, кто использует XML для обмена данными в новых проектах, то он либо не знает о JSON, либо конченных мазохист-извращенец
И это же ещё не затронута тема SOAP и SOAP-сервисов — топ-банки с этим ещё будут жить долго...
[item]
name=John Doe
city=London
Уж лучше yaml:
item:
name: John Doe
city: London
XML практически всегда применяется не по назначению