Почему никто до сих пор не реализовал валидацию совместимости XML? Почему никто даже не думает в этом направлении? Неужели я один такой, для кого отсутствие подобной фичи - мучительно? 

Что я имею в виду под валидацией совместиомости? Прежде чем открыть файло и пустить в обработку, я хочу быть уверенным, что я смогу его обработать. Для этого у меня есть ряд критериев, которые обязательно должны быть собюдены.  При этом мне глубоко безразлично, содержит ли XML избыточную для меня информацию, главное, чтобы он содержал достаточную.

К примеру.

Версия 0.0.1 некого интерфейса имела dtd

Я пишу некое приложение, использующее этот интерфейс, пускаю его в эксплуатацию. Прежде чем парсить интерфейсную XML, валидирую ее локально сохраненной версией DTD, мол соответствует, можно ли с ней работать.

Но тут кто-то меняет интерфейс на 

Для моего приложение этот формат - полностью совместим. Если я не собираюсь испльзовать нововвдение, мое приложение, в части разбора XML должно бы отсаться неизменным, однако новая вресяия XML не пройдет валидации сохраненной копией DTD. Потому что DTD проверяет на соответствие, не на совместимость.

Зачем вообще нужна валидация на соответствие? Помоему только в частном слуачае, когда разработчиком интерфейса является потребитель данных. Поставщик же данных к нему подстраивается, чтобы при генерации иметь возможность свериться, схавает ли потребитель подложенный ему формат.

В более же общем, с точки зрения практики, случае, когда поставщик выставляет во вне какие то данные, которые соответствуют определяемой им же спецификации, валидация нужна потребителям, которые к нему подстраивается, чтобы определить способны ли они с этим форматом работать. Т.е. им важна валидация совместимости их с форматом. Соответствует ли поставщик выставленному им же формату, потребителю - глубоко пофиг. Если даже не соответствует, главное чтобы с ним мог работать он сам.

Получается что валидация на соответствие, как бы не так уж и нужна оказывется.   

Вот такой вот сумбур у меня в голове. То-ли лыжы не едут, то-ли...


Это сообщение отредактировал(а) Zloxa - 21.7.2011, 12:35

Я не уверен, что понял в чем именно проблема, попробую сформулировать что я понял.
У тебя есть некая схема документа, с которым работает твое приложение. Далее схема меняется таким образом, что в новом документе появляются новые данные, при этом старые в нем тоже содержаться. Твоя задача состоит в том, чтобы выяснить, содержит ли новый документ нужные тебе данные, но старая схема(DTD) для этого не подходит.
Вопрос: что мешает использовать для валидации новую схему, ведь она подразумевает наличие в документе всех необходимых данных? Если новая схема допускает построение на ее основе документа, который твое приложение не "проглотит", то, возможно, надо создать какую-то промежуточную схему самому?

Подтверждаю . Контрольные суммы совпадают   

Для второго случая, когда потребитель подстраивается под формат поставщика информации, и поставщик может и не подозревать о наличии потребителя, валидация, мне думается, должна производится исключительно локальной копией схемы/dtd. Возьмем к примеру публикацию курсов валют на ЦБРФ. Если они на своем сайте одновременно изменят и спецификацию и формат xml, что даст потребителю валидация? XML останется валидным, но это ничего не говорит о том, можно ли брать его в работу. Потому, в этом случае, потребители должны держать у себя лоакльную копию схемы, с какой они однозначно умеют работать и валидироваться исключительно по ней. Однако, в случае, кода требуется подменить эту локальную копию схемы новой, придется проводить анализиы мозгом на предмет совместимости. Эта операция мне видится избыточной, и причина гемороя как раз в том, что проверяется соответствие, а не совместимоость. А соответствие, если вдуматься, оно и вовсе оказывается не важным. В первом случае тоже можно было бы обойтись совместимостью, строгое соответствие и там не особо нужно.


Это сообщение отредактировал(а) Zloxa - 21.7.2011, 13:25

А разве у тебя не этот случай?

Мы говорили о том случае, когда такие изменения не приводят к тому, что твоя программа перестает понимать документ. Если это не так, то естественно это ничего не даст.

Тогда мне интересно, как ты себе все это представляешь. Как вообще можно описать такую вещь как совместимость? Если, конечно, тебя не устраивает схема. Ведь для тебя понятие совместимости базируется исключительно на особенностях работы твоей программы, то есть на том, по каким критериям твоя программа ищет в документе ту или иную информацию. Как ты понимаешь, способов достучаться до тех или иных данных неисчислимое множество и какой из них выбрал ты при написании программы - неизвестно. В таком случае, если и говорить о совместимости, то, по всей видимости, подразумевается, что для ее определения потребуется какой-то достаточно сложный язык. И тут вопрос в том, есть ли смысл изобретать такой язык, если с этой задачей вполне можно справиться с помощью любого формата схемы, ну или почти любого, в зависимости от задачи.

Конечно для этого, по всей видимости, тебе потребуется написать собственную схему, по крайней мере в сложных случаях, но тут в любом случае, без какой-либо работы с твоей стороны не обойтись.

Для тех ситуаций, когда формат изменился настолько, что твоя программа его не хавает, можно использовать преобразование.

Ну не обойтись без этого в любом случае.

Смотря чему соответствие. Если схема является описанием того, с чем умеет работать твоя программа, то именно валидация решит твою проблему.

1. Не факт что после добавления новых тегов, программа останется работоспособной (безотносительно самой валидации).
2. Ты очень узко трактуешь "совместимость". Например: есть тег:

атрибут sex это перечисление в котором определены 2 типа. Спустя некоторое время, в нашей системе появляется новый тип пользователей бот. Никаких тегов не добавилось, но допустимые значения старых изменились. Можно ли считать такие изменения совместимыми?

Нет, конечно.
Но вот, если добавится тэг sexual_orienatiton, не представляю что могло бы меня закривить.

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

Это сообщение отредактировал(а) Zloxa - 21.7.2011, 15:37

Не, таки не поплохеет. Если у нас обязательный тэг стал не обязательным, то это уже явно потеря совместимости формата, а это, мне думается - единственная причина, по какой атрибут может сменить свою позицию в списке.

Не знаю что ты подразумеваешь под позиционной нотацией. Из тех способов, что знаю я: 
- SAX - сам по себе спокойно переварит, но твоему обработчику может и поплохеть
- DOM - то же самое
- "binding" - поплохеет, до тебя дело не дойдет
- XPath - отработает нормально
Итого из тех технологий что я знаю: 1 отработает нормально, 2 отработают нормально если при написании кода, заранее закладываться на такой результат.

Когда мы значение элемента определяем не по его имени, а по его положению в документе. Т.е. берем первый атрибут элемента, а не атрибут "sex", полагая что у нас единственный атрибут. Походу это то самое, что ты имел в виду, когда гвоорил что моему обработчику может поплохеть. Однако ж если задуматься- первый и первый. Если первый будет с другим именем, значит это уж не совместимый формат. А какие там у нас пятые и дейсятые атрибуты, нам пофигу, потому как мы не знаем о их сущесвтовании и знать не хотим.

не знаю что это.
Полагаю это когда свойства объекта сопосталяются с элементами XML в автоматическом режиме. Обычно эти вещи - как бы надстройка над домом и саксом - сиречь реализация. Потому, если б консорциум в3орг задумал рализовать столь очевидно необходимую шнягу в замен сомнительно нужной, но худо-бедно работающей, думаю, и биндинги не были бы столь стоги к формату входящих данных. В конце концов это опцией можно было бы сделать.

А разве имеет значение, в какой последовательности в документе определены атрибуты? В хмл это не имеет значения, на сколько я знаю, а стало быть и проверить это валидацией нельзя. Или в дтд есть такая возможность?  

А ты так и не написал в чем она состоит. Как мне кажется, понятие совместимости очень относительно: то, что совместимо с точки зрения логики твоей программы, совсем не обязательно совместимо со всех остальных точек зрения. Поэтому я так и не понял чего именно ты хочешь. Насколько я понял, задача твоя состоит в том, чтобы определить "съест" ли твоя программа "не совсем тот" документ или нет. А как ты себе представляешь логику такой тулзы, формата или что ты там еще хочешь? Я так понимаю, тебе надо, чтобы это делалось автоматически, поскольку, если потребуется твое вмешательство, то тут и схема вполне сгодится, а тебе надо чтобы само все сделало. И как это должно выглядеть?

DTD определеяет порядок следования элементов. ЭТо - точно. Атрибутов - не знаю, не доводилось, завтречка побалуюсь - проверю. Про атрибуты говорил потому что LSD пример с ними привел. Говоря о них я думал об элементах.


Можно и так сказать. Только задачи такой, как таковой, не стоит. Я просто досадую, что у меня нет такой возможности. Либо я о ней не сведущ. И недоумеваю, почему это досадно только мне.

Я ж уже отписал вкратце. Топикстарте. Я ожидаю увидеть элемент books, который содержит один или более элементов book, в каждом из которых я ожидаю увидить элемент isbn и буду рад увидеть элементы author,title,commеnt. Если в элементе books будут обнаружены другие элементы, почему меня это должно расстраивать?  Я отработаю криво, если при разборе, скажем DOMом,  отберу хпачем  элементы 'books/*' и стану обращться к ним по индексу. Но если я так не делаю, у меня как бы и нет возможности валидатору скзать, "забей на любые другие элементы, любого содержимого, контролируй только то, что описано в спецификации, остального для тебя - нет".  Ну или в локальной дтдшке прописать что "элемент books может содержать 0 или более любых элементов любой структуры и один или более элемент book, которые могут следовать в любом порядке". Но помому так не получится. Ни в dtd, ни в xsd.

Это сообщение отредактировал(а) Zloxa - 21.7.2011, 23:27

Например потому, что порядок следования элементов зачастую бывает важным. Не знаю как в дтд( больше XSD пользуюсь), но в принципе, в отличие от атрибутов порядок элементов на смысл документа влияет. 
Относительно атрибутов в принципе тоже можно спорить, поскольку не все хмл апи одинаково смотрят на этот вопрос. Сам сталкивался с тем, что некоторые имеют функцию сравнения узлов, но при этом если два элемента отличаются только порядком следования атрибутов, то они распознаются как разные. Но вообще порядок атрибутов схемой не определяется, атрибут - это просто свойство элемента.

Кроме того, к примеру, в элементе book может оказаться несколько элементов с одинаковыми именами в ситуации, когда программа ожидает только один такой элемент. Вот вопрос, надо считать этот документ совместимым или нет?
Скорей всего твоя программа ухватит первый элемент, хотя не факт, что нужен именно он, к тому же не факт, что в документе они будут всегда в этом порядке идти, например в другом элементе бук сначала может идти английское название.


Но вообще-то есть другая возможность. Всегда можно применить к существующему документу преобразование, которое приведет его к нужному виду. То есть к тому, который можно будет и проверить и обработать. Кто мешает написать преобразование, которое будет вырезать все элементы, кроме тех, которые действительно будут обрабатываться?

Если исходная разметка не допускает множественного повторения элемента, документ не совместим.

Хорошая идея. Спасибо  
Впрочем она, по рутинности, вполне сравнима с валидацией обработки, вроде того, чтобы после отработки  каждого икспача проверять, возвращены ли элементы, допустимое ли количество, возвращены ли обязательные.

Не доводилось, не можешь пояснить примером? Мне кажется это плохая практика закладываться на порядок следования элементов

А это из чего следует? А если в исходном документе их могло быть больше одного, а в новом просто возможное количество увеличилось? Ведь ты исходишь из того, что твоя программа берет единственный такой элемент, но ведь она вполне может при взятии такого элемента проверять значение какого-то атрибута, или к примеру, у той же книги может быть несколько авторов, а для каждого автора есть только один тег. Получается для такого документа вообще совместимых форматов не существует? Я еще раз повторяю, что понятие совместимости, в том виде, в котором ты пытаешься его определить, не является чем-то универсальным и применимым для всех случаев. Это понятие завязано исключительно на том, как именно твоя программа обрабатывает документы данного типа.

У тебя будет одна схема и один алгоритм обработки документа. Они меняться не будут вообще, а все документы, которые поступают на обработку, ты будешь сначала обрабатывать преобразованием, которое приведет их в подходящий для этого вид. Я такой подход вообще использую для загрузки данных в программу. В твоем любимом дойтнете   есть компонент DataSet, который представляет набор таблиц и связей для работы с данными в программе. У него есть методы ReadXml и WriteXml со вполне понятным назначением. Так вот при использовании этих методов я вообще не имею возможности управлять алгоритмом обработки документа, поскольку они понимают вполне конкретный формат. В тоже самое время, я считаю использование этих методов чрезвычайно удобным, поскольку логика обработки данных обычно сводится к тому, что я пишу преобразование в формат понятный датасету и загружаю результат этого преобразования, что называется "легким движением руки". При этом логика программы никогда не меняется, независимо от того, как изменился формат поступающих данных. Все что надо закладывается в XSLT.


Я согласен, что это плохая практика в большинстве случаев. Но я исхожу из того, что: во-первых, возможность такого описания документа заложен в схеме(элемент sequence в xsd); во-вторых, ты не всегда контролируешь то, с чем работаешь, ты можешь получить документ извне и в спецификации будет сказано, что первый элемент item в таком-то наборе означает то, а второй - это; ну и в-третьих, иногда бывает, что элементов в наборе достаточно много и обрабатывать их, указывая каждый по имени будет достаточно сложно, в то же время в наборе данных, в который заносится результат обработки все элементы следуют в том же порядке, что и в документе.
Строгость при составлении документа имеет свои преимущества, в частности простоту обрабатывающего кода, а для сложных документов это может оказаться критичным. Я понимаю, что ты сейчас скажешь, что такие документы несовместимы, но мне почему-то думается, что если попытаться представить себе какой-то универсальный набор правил, который бы описывал совместимость документов, то сформулировать его вряд ли было бы возможно. Слишком уж много нюансов пояляется при рассмотрении конкретных примеров, коих тыщи.

Для аттрибутов, порядок вообще дело десятое. Я говорил немного про другое, про сами теги. Смотри был у нас такой документ:

а потом мы его расширили и получили:

и далеко не факт, что наш SAX обработчик поймет какие из *-name тегов ему надо прочитать, а какие проигнорировать.



Да, это оно самое.



Смотри: XML документ это некий набор данных, записаных в соответствии с определенным синтаксисом и имеющих определенную семантику. Ни DTD ни XSD проверить семантику не могут, они могут проверить только синтаксис. Правильный синтаксис не гарантирует, что семантика правильная, но повышает шансы на это. Во всяком случае неправильный синтаксис, в подавляющем большинстве случаев приводит к неправильной семантике.
Ты утверждаешь, что расширение синтаксиса не влияет на семантику (в большинстве случаев) и по умолчанию расширение надо разрешить. На мой взгляд, это не далеко не всегда так (и похоже W3C того же мнения  ). Смотри был у нас такой тег:

в который мы писали адрес целиком, потом решили разбить его на поля и получили:

синтаксически тег остался, но по сути семантика его изменилась. И подобных вещей может быть много, потому W3C посчитали, что fail fast будет более оптимальным. А если ты уверен, что расширение синтаксиса тебе лично не помешает, ты можешь использовать в XSD "any" теги и атрибуты  


P.S. Было бы забавно, если бы компилятор просто игнорировал все синтаксически неверные конструкции и компилировал только синтаксически правильные