xmlhack.ru XML-форумы
Обсуждение XML и связанных с ним технологий

Элементы или атрибуты? by taler


Автор Сообщение
taler
Аспирант

Зарегистрирован: 28.04.2002
Сообщения: 113

[1862] Чт Авг 29, 2002 23:00
Элементы или атрибуты? by taler
Тема эта глубочайшая (гигантский айсберг), тогда как (сорри, исключительно имха) статья выше выглядит поскребыванием ножиком по маленькой внешней гладкой поверхности (все-таки склонен думать, что атрибуты или элементы - лишь следствие чего-то еще, но вовсе не самоцель. Самое важное все еще определяется тем, с какой целью создается конретный компонент или документ в целом). Вот некоторые мысли и замечания:

(c)Taler) : Элементы и атрибуты (30 авг. 2002)
===================

1) Вкусы и предпочтения. На самом деле, часть дискуссий об атрибутах и элементах проистекает из персональных предпочтений. Многие, хотя и не все, аргументы можно свести к: "мне больше нравится то, а не это". XML предоставляет и элементы и атрибуты, и то и другое не исчезнет, и в принципе, вы вольны использовать и то и это. В ряде "локальных" (!) случаев это может быть сугубо делом личных предпочтений и собственного стиля мышления.

2) Кооперативность сообществ. Процесс структурирования и достижение любых соглашений - это бизнес-задача, и как таковая, ДОЛЖНА включать консенсус ВСЕХ участников. Нередко программисты, "нюхом чувствующие" преимущества XML, начинают применять его в своих системах без каких-либо консультаций с персоналом, ответственным за биснес. Как результат, документы становятся непрактичными, неюзабельными (о XML-юзабилити в см. ниже), серьезно осложняется интероперабельность. Именно сообщества вырабатывают соглашения. Как пример, федеральные органы США имеют собственные правила типа "Standardization of Data Elements" (речь чисто об xml), которые делятся на "классы объектов, свойства и представления",

3) Структура (информационный дизайн). Структура должна быть максимально простой, однако данные должны включать ВСЕ присущие им отношения. Это самое сложное положение, связанное с понятием "информационной артектуры" в целом, но по этой теме для краткости пройдемся лишь несколькими тезисами из как минимум 287-ми возможных Wink.

3a). В качестве возможной отправной точки, вероятно, можно принять каноническое представление Леймана [*"XML Syntax Recommendation for Serializing Graphs of Data."* ссылка на его статью есть в списке литературы документа - жаль, что с 1998г. он вроде бы забросил эту тему]. В той ранней работе Лейман "канонизирует" данные исключительно в виде элементов, а атрибуты играют лишь роль ссылок. Вообще-то тема его статьти больше графовая, но когда я первый раз наткнулся на его работу, мне подумалось, что нередко для формальных и прозрачных структур на XML это какая-никакая, но одна из отправных точек - но не путать со стандартом Canonical XML]. Под 'каноническим представлением' Леймана понимается такое представление информации в XML, когда информационные объекты представляются элементами, а их свойства и отношения между объектами - вложенными элементами, имеющими атрибуты-ссылки.

Далее (уже отвлекаясь от тем канонизации или де-канонизации) просто приведу пример "плохой" структуры (ведь так и напрашивается спросить, почему zipcode структурно оторван от остальных данных?):

Код:

<address zipcode="84012">
  <city>...</city>
  <street>...</street>
  <number>...</number>
</address>


Более лучшая структура (и обратите внимание на понятие 'type'):

Код:

<address type="business">
  <city>...</city>
  <street>...</street>
  <number>...</number>
  <zipcode>...</zipcode>
</address>



3b). Ограничения. Как известно, структурно атрибуты в принципе не эквивалентны элементам (они не структурируются, не могут иметь пустого содержимого, сложно задать их множественные значения, один атрибут в элементе не может присутствовать несколько раз и т.д.)

3с) Различия тексто-ориентированной разметки и разметки данных. Хорошо известно, что выбор между элементами и атрибутами ортогонален для тексто-ориентированного подхода и подхода, ориентированного на данные (или объекты данных).

Классика, что для задач текстообработки текст лучше помещать в элементы, а не в атрибуты. Cуществующая практика работы с текстами такова, что за атрибутами закреплена роль "мета-информации", роль вторичная/служебная. Разница в том, должен ли потенциальный читатель или программма-робот видеть "мета"? Нужна ли ему эта информация.. ? Вот откуда "желание" броузеров не показывать атрибуты. Например, для части приложений, работающих с вашим XML, "мета в атрибутах" могут быть даром не нужны. (Только зачем же вот так вот "предавать анафеме" любые модели?)
taler
Аспирант

Зарегистрирован: 28.04.2002
Сообщения: 113

[1863] Чт Авг 29, 2002 23:00
Элементы и атрибуты (ч. II)
3d) Реляционные БД и таблицы. В задачах, непосредственно связанных с обменом таблицами с РБД, манипулировать данными нередко (не всегда) проще, когда это атрибуты, нежели элементы.

3с) Отношения между данными. Вот где кроется глыба, и она связана прежде всего с моделями обработки. Приведем простой любопытный пример. Допустим, вы сделали сетевой XML-каталог вида:

Код:

 љ<cellphone id="627..">
 љ<property name="vendor" value="Nokia" />
 љ<property name="weight" value="10" />
 љ<property name="battery" value="2" />
 љ ....
</cellphone>


Не замечаете ли вы, к примеру, в этой структуре врожденные пороки, которые могут негативно сказаться на обработке. Какие? Ну, разумеется, нет сомнений, вы сами не ошибетесь с запросами (вы-то знаете свои данные). А как насчет персонала в доме напротив (назовем его "секретаршей") - правильно ли она составит запрос (даже если ей "организовали" GUI)? Здесь очевидный недостаток - љатрибуты name и value не связаны друг с другом, их связь опосредованная. И "недостаточно сильный юзер" может подумать, что для поиска телефончика, батарейка которого работает 10 часов, как ему кажется, сгодится следующий XPath:

Код:

cellphone[property/@name="battery" AND
 љ љ љ љ љ property/@value="10"]


Ну и зачем, чтобы к вам сыпались звонки с претензиями, ибо результат такого запроса будет совершенно неправильным - он найдет на вашей "home-page" телефоны, у которых (одновременно) есть и элемент property с name="battery", и еще один элемент property с value="10", но это будут совершенно разные свойства и кто-то получит неизвестно что.

3d) Далее не будем забывать, что XML намного богаче по структурам, чем простые линейные, табличные или деревянные модели. Структуры каталогов и таксономии/онтологии - несколько другие вещи, чем простой текст или таблицы. И даже для "чисто данных" понятие "мета" никуда не исчезает - оно перерождается в "более тонкое". Пример возможного подхода к дизайну - различать глаголы "имеет" или "описывается". Вероятно, в любом случае (имхо) понятию "иметь, обладать" более соответствуют дочерние элементы, тогда как понятию "описывать" - атрибуты.

Кроме того, поскольку на XML можно выражать графы, то никто не мешает на XML моделировать и объектные отношения - не только "has-a", но и 'is-a", а 'is-a" - простите, но is-a - это уже классы, наследования, особенно множественое наследование и пр. (Структура "объект"- "свойство" - это же естественные семантические единицы,) Замечу, что в последнее время различные тенденции здесь особенно бурно развиваются. Однако проблема взаимоотношения элементов и атрибутов в этой плоскости - это как бы отдельный разговор.

5) есть еще такие понятия, как размер файлов, скорость обработки и т.д.

6) Юзабилити (Семантическая интероперабельность, контекстно-зависимая обработка и распознавание чужих XML "патернов", "типов" и "стереотипов").
Вот тут я хотел бы сказать, что это одно из главных:

Учтите, вы создаете XML не для себя - вы создаете его во многом для интероперабельности и повышения юзабилити (XML, согласно Бернерс-Ли, лишь нижний уровень семантической этажерки в нашей сети, и уж если вы делаете для сети - так хоть чтобы ваши данные обязательно могла прочесть программа). Поэтому те понятия, что вы вкладываете в свой язык, должны быть важнейшей частью вашего информационного дизайна. (Все факторы, рассмотренные выше, включая оперирование "числом отношений", нуль, ничто, zero по сравнению с XML-юзабилити). Возьмем следующий XML-файл:

Код:

<city id="063:0" name="Tbilisi">
 љ љ<country id="063" name="GEORGIA"/>
 љ љ<is-capital>true</is-capital>
 љ љ<longitude>44.48</longitude>
 љ љ<latitude>41.43</latitude>
 љ љ<source>The Times Atlas of the World,1992</source>
</city>
<city id="064:0" name="Berlin">
 љ љ<country id="064" name="GERMANY"/>
 љ љ<is-capital>true</is-capital>
 љ љ<longitude>13.25</longitude>
 љ љ<latitude>52.32</latitude>
</city


Казалось бы, что тут особенного? Но обратите внимание, љвам достаточно "три-притопа" (или дюжины операторов на xslt), и ваш "автоматический секретарь" способен легко построить онтологию такого языка (грубо говоря, терминологическую вложенность), например, вида

Код:

cities
 city
 ћ country
 ћ is-capital
 ћ longitude
 ћ latitude
 ћ source (url)


или, еще например, для какого-нибудь СomicsML (типа http://www.outer-court.com/tech/msie5pt4.htm) вы тоже легко построите нечто вроде:

Код:

comic
 љ=ћ company
 љ=ћ title
 љ=ћ subtitle
 љ=ћ issue
 љ=ћ pencils
 љ=ћ content
 љ=ћ price
 љ=ћ status
 љ=ћ comment


Как говорится - No problem, было бы из чего строить. И такое содержимое вам уже кажется "прозрачным". И в то же время, попробуйте построить нечто аналогичное из того, что ниже (нет, далеко не худший пример). Однако насколько все "сложнее":

Код:

<root>
<node id="212" label="http://www....хml">
<att name="title" value="Java Bytecode Examples"/>
<att name="mime" value="text/html"/>
<att name="size" value="7607"/>
<att name="date" value="Fri Jun 14 11:08:38 1996"/>
<att name="code" value="200"/>
</node>
</root>


Почувствуйте разницу... (уж не привожу еще более худшие примеры - люди так обидчивы.) љ

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