IT-redneck

Херассе забабоны.
А какой смысл могут нести такие ограничения, если при обработке все равно элементы по имени искать придется?

From:

+1
вообще хорошо бы увидеть пример в виде такого XML

From:

<?xml version="1.0" encoding="UTF-8"?>
<!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 и никак иначе, даже если это кому-то не нравится.

From:

volodymir-k.livejournal.com

> при обработке все равно элементы по имени искать

Слышали, что такое DOM, SAX?

From:

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

From:

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

From:

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

From:

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

From:

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

From:

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

From:

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

From:

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

From:

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

From:

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

From:

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

From:

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

From:

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

From:

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

From:

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

From:

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

From:

From:

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 в любой ВАШ объект.

From:

Хороший вопрос, наверно для порядка :)
Я тоже поначалу думал что это зря, но потом представил себе насколько проще (по загрузке машины) с такой структурой раобтать XSLT процессору. Особенно в случае если элементов с тем же самым названием может быть много.
Ну или вот например если выражение работает не по имени тега а по другим признакам а надо чтобы порядок был, тогда при трансформации чтобы создать упорядоченный список надо процессить ещё раз - грузить машину сортировкой, в то время, как источник данных это прелестно может сделать.
Ну и последнее, чисто пользовательское, вот в банальном HTML приятно будет head искать где угодно или лучше непосредственно перед body?

From:

XSLT разве использует DTD для работы? А без DTD ему по идее неоткуда узнать о встроенном порядке.

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

From: