О чтении и понимании

[metaclass]

Нужно обмениваться данными с другой программой. Сделал для ее разработчиков документ с описанием формата на базе CSV, в котором есть такие строки:

"дата - формат dd.mm.yyyy, с выводом незначащих нулей."

"в первых трех строках последнее поле не указано, поэтому в конце строки стоит ;" (Всего полей шесть, последнее может быть пустым и чтобы парсеру не обрабатывать частные случаи - пустое последнее поле должно быть).

Присылают файл с такими строками:
"10780;11077112;31.03.2009;1.04.2009;1014"

Вопрос, что я объяснил не так?

Comments

[metaclass.livejournal.com]

Да, в DOM я такие элементы буду искать по имени. Что нибудь вроде SelectSingleNode.
В SAX сделаю три переменных и в вызове обработчика для элемента буду заполнять их, проверяя имя элемента.
И уж всяко не стану надеятся на порядок их расположения в файле - мало ли что там может быть, например комментарий кто-нибудь всунет или еще хрень какую.

[vp.livejournal.com]

все равно не понятно каким боком может на что-то влиять мифический порядок элементов. Это ж технологии парсинга, не более того.

[metaclass.livejournal.com]

Не, вообще парсеры есть которые проверяют DTD, и соответственно, в таком случае будут проверять порядок элементов.
Но на выходе парсера обычно или дерево DOM или последовательность дерганий событий в случае SAX. Чем им поможет заданная последовательность элементов - не представляю, для меня это выглядит как аналог обращения к полям в БД по индексу Field[0], Field[2] и отгребания потом по полной программе, когда в запросе поля не в том порядке.

[sergiej.livejournal.com]

А если такова и есть задача - запросить поля по порядку, а не по имени? Вместо того чтобы жёстко "хардкодить" имена? Там ведь куча других параметров или выраженй по которым я могу нод дёргать, может его имя это последнее что меня интересует (хочу, к примеру создать табличку записи-поля которые имеют аттрибут "обязательный" а полей сотни не перечисляя всех сотен). Чтобы можно было решить такую задачу и добавили.
Кроме того "орднунг".

[metaclass.livejournal.com]

Не, не врубаюсь, особенно в пример с табличкой полей. Если дергать нод по XPath, там вроде можно по номеру к детской ноде обращаться, но имхо ничего хорошего с этого не получится :)

[sergiej.livejournal.com]

Ну плохая эта практика, но если нужно? Данные могут быть по полям упорядочены? Могут. Вот и введена такая возможность. Вот самый тупой пример, мне нужно XLS перевести в XML и обратно. В XLS всё построено на порядке следования. Мне что каждому полю кроме его названия ещё и его букву внутри XLS присобачивать чтобы потом обратно XLS создать?

[metaclass.livejournal.com]

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

[vp.livejournal.com]

Говно вопрос. XML это обобщенное хранилище данных, потому если нужны какие-то сущности сверх этого - это нужно реализовывать руками. Нужен порядок - извольте именовать поля как field1=xxx field2=xxx, потом грузите и сортируйте. Никто не обещает, что наши фантазии на тему XML будут поддерживаться и сохраняться при каком-нибудь пересохранении.

[sergiej.livejournal.com]

Вы что-то путаете, XML это обобщённый язык разметки. Если для разметки требуется последовательность данных разной сущности то XML должен это обеспечивать, что он и делает.

[vp.livejournal.com]

я не про то подумал. Я думал речь и идет о том, в каком порядке тэги идут, и что народ тэги по номерам вытягивает. Теперь все понятно и я полностью согласен. :)

[metaclass.livejournal.com]

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

[sergiej.livejournal.com]

Так кто его всунет если он не будет разрешён схемой в этой последовательности?

[metaclass.livejournal.com]

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

[sergiej.livejournal.com]

А пардон, правильный коментарий просто не существует, но тогда и проблемы то нет, он не вмешивается в последовательность.

[metaclass.livejournal.com]

Вмешивается. В DOM модели он точно присутствует за каким-то хреном.

[sergiej.livejournal.com]

Блин, ну да, в DOM есть всё, до последней запятой.

[sergiej.livejournal.com]

:)

[volodymir-k.livejournal.com]

Для Вас XML это вид реляционной БД. Это в общем случае неверно -- используется Builder pattern, то есть это сложные и нерегулярные структуры данных. Понятно, что замапить любую структуру данных в реляционную можно, просто потом довольно трудно использовать SQL. Попробуйте на SQL реализовать какие-нибудь самобалансирующиеся AVL trees. Пупок развяжется.

Для решения этой проблемы и придуман DTD / XSD. Последний -- достаточно сатанинский "а-ля функциональный" язык. Например, не всякий XSD можно перевести в DTD. У XSD есть диалекты и т.д. Валидация это серьёзная тема, если Вы не понимаете её -- то скорее это Вы неправы, чем сотни опытных людей из всяких комитетов.

Для обработки регулярных структур тупой поиск по имени не подходит. Скажем, у элемента config-array будут идти последовательности из трёх строчек a1/b0/z0, не объединённые в свой элемент, их надо класть в массив. Тогда обработчик SAX должен третий элемент z0 считать разделителем объектов.

Примерно такой подход в Яве реализован в commons-digester. Мощнейшая штука. Даёте XML описание, получаете программу парсания XML в любой ВАШ объект.