XML-форумы | |
Обсуждение XML и связанных с ним технологий |
Автор | Сообщение | |
---|---|---|
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-ми возможных . 3a). В качестве возможной отправной точки, вероятно, можно принять каноническое представление Леймана [*"XML Syntax Recommendation for Serializing Graphs of Data."* ссылка на его статью есть в списке литературы документа - жаль, что с 1998г. он вроде бы забросил эту тему]. В той ранней работе Лейман "канонизирует" данные исключительно в виде элементов, а атрибуты играют лишь роль ссылок. Вообще-то тема его статьти больше графовая, но когда я первый раз наткнулся на его работу, мне подумалось, что нередко для формальных и прозрачных структур на XML это какая-никакая, но одна из отправных точек - но не путать со стандартом Canonical XML]. Под 'каноническим представлением' Леймана понимается такое представление информации в XML, когда информационные объекты представляются элементами, а их свойства и отношения между объектами - вложенными элементами, имеющими атрибуты-ссылки. Далее (уже отвлекаясь от тем канонизации или де-канонизации) просто приведу пример "плохой" структуры (ведь так и напрашивается спросить, почему zipcode структурно оторван от остальных данных?): Код: <address zipcode="84012">
Более лучшая структура (и обратите внимание на понятие 'type'): Код: <address type="business">
3b). Ограничения. Как известно, структурно атрибуты в принципе не эквивалентны элементам (они не структурируются, не могут иметь пустого содержимого, сложно задать их множественные значения, один атрибут в элементе не может присутствовать несколько раз и т.д.) 3с) Различия тексто-ориентированной разметки и разметки данных. Хорошо известно, что выбор между элементами и атрибутами ортогонален для тексто-ориентированного подхода и подхода, ориентированного на данные (или объекты данных). Классика, что для задач текстообработки текст лучше помещать в элементы, а не в атрибуты. Cуществующая практика работы с текстами такова, что за атрибутами закреплена роль "мета-информации", роль вторичная/служебная. Разница в том, должен ли потенциальный читатель или программма-робот видеть "мета"? Нужна ли ему эта информация.. ? Вот откуда "желание" броузеров не показывать атрибуты. Например, для части приложений, работающих с вашим XML, "мета в атрибутах" могут быть даром не нужны. (Только зачем же вот так вот "предавать анафеме" любые модели?) |
|
taler Аспирант Зарегистрирован: 28.04.2002 Сообщения: 113 |
[1863]
Чт Авг 29, 2002 23:00
3d) Реляционные БД и таблицы. В задачах, непосредственно связанных с обменом таблицами с РБД, манипулировать данными нередко (не всегда) проще, когда это атрибуты, нежели элементы.
Элементы и атрибуты (ч. II) 3с) Отношения между данными. Вот где кроется глыба, и она связана прежде всего с моделями обработки. Приведем простой любопытный пример. Допустим, вы сделали сетевой XML-каталог вида: Код: љ<cellphone id="627..">
Не замечаете ли вы, к примеру, в этой структуре врожденные пороки, которые могут негативно сказаться на обработке. Какие? Ну, разумеется, нет сомнений, вы сами не ошибетесь с запросами (вы-то знаете свои данные). А как насчет персонала в доме напротив (назовем его "секретаршей") - правильно ли она составит запрос (даже если ей "организовали" GUI)? Здесь очевидный недостаток - љатрибуты name и value не связаны друг с другом, их связь опосредованная. И "недостаточно сильный юзер" может подумать, что для поиска телефончика, батарейка которого работает 10 часов, как ему кажется, сгодится следующий XPath: Код: cellphone[property/@name="battery" AND
Ну и зачем, чтобы к вам сыпались звонки с претензиями, ибо результат такого запроса будет совершенно неправильным - он найдет на вашей "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">
Казалось бы, что тут особенного? Но обратите внимание, љвам достаточно "три-притопа" (или дюжины операторов на xslt), и ваш "автоматический секретарь" способен легко построить онтологию такого языка (грубо говоря, терминологическую вложенность), например, вида Код: cities
или, еще например, для какого-нибудь СomicsML (типа http://www.outer-court.com/tech/msie5pt4.htm) вы тоже легко построите нечто вроде: Код: comic
Как говорится - No problem, было бы из чего строить. И такое содержимое вам уже кажется "прозрачным". И в то же время, попробуйте построить нечто аналогичное из того, что ниже (нет, далеко не худший пример). Однако насколько все "сложнее": Код: <root>
Почувствуйте разницу... (уж не привожу еще более худшие примеры - люди так обидчивы.) љ Пожалуй, можно остановиться. Но одно мне неясно, как можно ставить вопрос "атрибуты или элементы", не привязав свою задачу или не спозиционировав свой взор на конкретном (хотя бы кило-)метре айсберга... |
Страница 1 из 1 |