![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
О чтении и понимании
Нужно обмениваться данными с другой программой. Сделал для ее разработчиков документ с описанием формата на базе CSV, в котором есть такие строки:
"дата - формат dd.mm.yyyy, с выводом незначащих нулей."
"в первых трех строках последнее поле не указано, поэтому в конце строки стоит ;" (Всего полей шесть, последнее может быть пустым и чтобы парсеру не обрабатывать частные случаи - пустое последнее поле должно быть).
Присылают файл с такими строками:
"10780;11077112;31.03.2009;1.04.2009;1014"
Вопрос, что я объяснил не так?
"дата - формат dd.mm.yyyy, с выводом незначащих нулей."
"в первых трех строках последнее поле не указано, поэтому в конце строки стоит ;" (Всего полей шесть, последнее может быть пустым и чтобы парсеру не обрабатывать частные случаи - пустое последнее поле должно быть).
Присылают файл с такими строками:
"10780;11077112;31.03.2009;1.04.2009;1014"
Вопрос, что я объяснил не так?
no subject
no subject
no subject
<!ELEMENT чел (возраст, рост, пол)>
если пол будет перед ростом, то файл невалидный.
no subject
А какой смысл могут нести такие ограничения, если при обработке все равно элементы по имени искать придется?
no subject
вообще хорошо бы увидеть пример в виде такого XML
Такой пойдёт?
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>title</title>
</head>
<body>
<p>page</p>
</body>
</html>
Используемый http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd предполагает head непосредственно перед body и никак иначе, даже если это кому-то не нравится.
no subject
Слышали, что такое DOM, SAX?
no subject
В SAX сделаю три переменных и в вызове обработчика для элемента буду заполнять их, проверяя имя элемента.
И уж всяко не стану надеятся на порядок их расположения в файле - мало ли что там может быть, например комментарий кто-нибудь всунет или еще хрень какую.
no subject
no subject
Но на выходе парсера обычно или дерево DOM или последовательность дерганий событий в случае SAX. Чем им поможет заданная последовательность элементов - не представляю, для меня это выглядит как аналог обращения к полям в БД по индексу Field[0], Field[2] и отгребания потом по полной программе, когда в запросе поля не в том порядке.
no subject
Кроме того "орднунг".
no subject
no subject
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
Для решения этой проблемы и придуман DTD / XSD. Последний -- достаточно сатанинский "а-ля функциональный" язык. Например, не всякий XSD можно перевести в DTD. У XSD есть диалекты и т.д. Валидация это серьёзная тема, если Вы не понимаете её -- то скорее это Вы неправы, чем сотни опытных людей из всяких комитетов.
Для обработки регулярных структур тупой поиск по имени не подходит. Скажем, у элемента config-array будут идти последовательности из трёх строчек a1/b0/z0, не объединённые в свой элемент, их надо класть в массив. Тогда обработчик SAX должен третий элемент z0 считать разделителем объектов.
Примерно такой подход в Яве реализован в commons-digester. Мощнейшая штука. Даёте XML описание, получаете программу парсания XML в любой ВАШ объект.
no subject
Я тоже поначалу думал что это зря, но потом представил себе насколько проще (по загрузке машины) с такой структурой раобтать XSLT процессору. Особенно в случае если элементов с тем же самым названием может быть много.
Ну или вот например если выражение работает не по имени тега а по другим признакам а надо чтобы порядок был, тогда при трансформации чтобы создать упорядоченный список надо процессить ещё раз - грузить машину сортировкой, в то время, как источник данных это прелестно может сделать.
Ну и последнее, чисто пользовательское, вот в банальном HTML приятно будет head искать где угодно или лучше непосредственно перед body?
no subject
Я эту пакость воспринимаю как усложненный вариант БД, а в реляционных БД множество колонок и кортежей не упорядоченное, поэтому всегда сортирую отдельно.
no subject
Одни парсеры и процессоры используют DTD, другие не используют, третьи могут использовать по желанию. Да и не в DTD дело, самый популярный XSD тоже имеет sequence, и оно широко используется.
Есть достаточное количество специфических задач в котором оно нужно. Да тот же CSV о котором пост и есть такой тип данных где порядок критичен.
Вот тут http://www.ibm.com/developerworks/xml/library/x-eleord.html товарисч пытается объяснить этот экзестенциальный вопрос, нужно оно или не нужно.
no subject
no subject
no subject
А так насчёт того, что бы товарищи у себя проверяли на валидность xml-я - вполне согласен
no subject
no subject
[Definition: The XML document type declaration contains or points to markup declarations that provide a grammar for a class of documents. This grammar is known as a document type definition, or DTD. The document type declaration can point to an external subset (a special kind of external entity) containing markup declarations, or can contain the markup declarations directly in an internal subset, or can do both. The DTD for a document consists of both subsets taken together.]
no subject
http://en.wikipedia.org/wiki/Document_Type_Definition
no subject
Ну вообще DTD не отделим от XML. А схема (relax-ng, или XML Schema) всё - таки внешняя сущность.
no subject
(no subject)