<?xml version="1.0" encoding="utf-8" ?>
<rss version="2.0" xmlns:content="http://purl.org/rss/1.0/modules/content/"
				   xmlns:wfw="http://wellformedweb.org/CommentAPI/"
				   xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
	<atom:link href="http://enumerate.ru/feed/wide" rel="self" type="application/rss+xml" />
	<title>Комментарии к записи "Идеальная расширяемость: пространства имён в XML"</title>
	<link>http://enumerate.ru/art/xml_namespaces</link>
	<description>Лента комментариев к записи "Идеальная расширяемость: пространства имён в XML" драматически экспериментального блога</description>
	<language>ru</language>
	<lastBuildDate></lastBuildDate>
	<generator>Funny RSS generator</generator>
	<managingEditor>din@mandatory.ru (Din Neville)</managingEditor>
	<webMaster>din@mandatory.ru (Din Neville)</webMaster>



<item>
	<title>Дин</title>
	<link>http://enumerate.ru/entry/xml_namespaces#_1103</link>
	<pubDate>Wed, 28 Jan 2009 19:51:54 +0600</pubDate>
	<description> <![CDATA[ @SelenIT, стандарт определения формата описания элементов и атрибута пространств имён никем не задан и не стандартизирован. Здесь ситуация несколько иная, нежели чем с DTD.

Сами списки элементов нигде не хранятся. Тот URI, который указывается в качестве значения атрибута xmlns (или xmlns:), он, всего-лишь, уникальный идентификатор этого самого пространства имён. Остальное остаётся за разработчиком, который создал это пространство: либо описать конкретно каждый элемент и каждый атрибут, который он использовал в документе в рамках конкретного пространства имён, либо не делать ничего.

Станет намного лучше, если в будущем появится формат описания конкретных элементов. Пока же разные разработчики по-разному применяют этот формат.

Сам <a href="http://www.w3.org/XML/1998/namespace">XML Namespace</a>, к примеру, определён достаточно порядочно: описано его назначение, некоторые атрибуты и даны полезные (связанные с пространством) ссылки.

Microsoft пошла по правильному, считаю, пути: она на странице к определённому пространству имён даёт ссылки на XML Schema, которая соответствует документу. В ней-то и описаны все элементы и атрибуты со всевозможными пространствами имён. В качестве примера подойдёт <a href="http://schemas.microsoft.com/project/2007/">Microsoft Office Project 2007 XML Data Interchange</a>. ]]> </description>
	<author>din@mandatory.ru (Din Neville)</author>
	<category></category>
	<guid>http://enumerate.ru/entry/xml_namespaces#_1103</guid>
	<wfw:commentRss></wfw:commentRss>
	
</item>

<item>
	<title>SelenIT</title>
	<link>http://enumerate.ru/entry/xml_namespaces#_1102</link>
	<pubDate>Wed, 28 Jan 2009 18:18:23 +0600</pubDate>
	<description> <![CDATA[ Спасибо, давно хотел найти что-нибудь подобное, популярное (наверное, я немножко девушка в душе:). Но почему-то эти загадочные штуковины &mdash; неймспейсы которые &mdash; остались для меня не менее загадочными, чем раньше. Никак не могу взять в толк, где хранятся сами списки имен для того или иного пространства. По ссылке на DTD хотя бы открывается реальный документ, который можно &laquo;оттрепанировать&raquo; (кстати, еще раз спасибо за то объяснение!), а что реально соответстветствует URI неймспейса? Или я вообще фатально не ухватываю суть? ]]> </description>
	<author>din@mandatory.ru (Din Neville)</author>
	<category></category>
	<guid>http://enumerate.ru/entry/xml_namespaces#_1102</guid>
	<wfw:commentRss></wfw:commentRss>
	
</item>

<item>
	<title>Tenshi</title>
	<link>http://enumerate.ru/entry/xml_namespaces#_1101</link>
	<pubDate>Sun, 25 Jan 2009 18:59:24 +0600</pubDate>
	<description> <![CDATA[ или другой пример — форматы rss1.0, 2.0 и atom по структуре своей квазиидентичны — разница лишь в именах и пространствах имён. почему нужно создавать несколько отдельных потоков в разных форматах, если можно сделать один и в отдельном файле указать, что использованный у нас тут my:album эквивалентен rss1:channel | rss2:channel | atom:feed ]]> </description>
	<author>din@mandatory.ru (Din Neville)</author>
	<category></category>
	<guid>http://enumerate.ru/entry/xml_namespaces#_1101</guid>
	<wfw:commentRss></wfw:commentRss>
	
</item>

<item>
	<title>Дин</title>
	<link>http://enumerate.ru/entry/xml_namespaces#_1100</link>
	<pubDate>Sun, 25 Jan 2009 18:57:02 +0600</pubDate>
	<description> <![CDATA[ @Tenshi, Ваше мнение, в принципе, понятно. Спасибо, что поделились. ]]> </description>
	<author>din@mandatory.ru (Din Neville)</author>
	<category></category>
	<guid>http://enumerate.ru/entry/xml_namespaces#_1100</guid>
	<wfw:commentRss></wfw:commentRss>
	
</item>

<item>
	<title>Tenshi</title>
	<link>http://enumerate.ru/entry/xml_namespaces#_1099</link>
	<pubDate>Sun, 25 Jan 2009 18:46:57 +0600</pubDate>
	<description> <![CDATA[ хороший язык должен быть простым и удобным сам по себе, а не требовать использования нетривиальных идей. 
xmlschema — это механизм валидации. я же говорил о семантике. вот возьмём, например, rss1.0 - там можно использовать rss:title (заголовок фида), а можно dc:title (абстрактный заголовок), а можно и my:album (заголовок альбома). при этом классы rss:title и my:album являются различными, но конкретно вот в данном месте элемент является экземпляром их обоих. 
единственно решение такого конфликта в совеременном xml — вкладывать тэги друг в друга, но получается, что некоторым клиентам придут чужие вложенные тэги, а другие не смогут найти свои (ибо ищут их на первом уровне вложенности), что может привести к плачевным последствиям.
а понимать смысл тэгов должен не только человек, но и робот. чтобы знать, например, что выводить в заголовок окна при отображении нашей xml-ки. ]]> </description>
	<author>din@mandatory.ru (Din Neville)</author>
	<category></category>
	<guid>http://enumerate.ru/entry/xml_namespaces#_1099</guid>
	<wfw:commentRss></wfw:commentRss>
	
</item>

<item>
	<title>Дин</title>
	<link>http://enumerate.ru/entry/xml_namespaces#_1094</link>
	<pubDate>Sun, 25 Jan 2009 15:07:49 +0600</pubDate>
	<description> <![CDATA[ @Tenshi, у вас получилось гораздо сложнее, чем аналогичное использование XML Namespaces. 

Я не согласен, что последние являются «фигнёй» только из-за того, что они не поддерживают вложенность и заставляют писать префиксы перед именами элементов. 

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

А вот по поводу массивности — решается современными XML-редакторами, которые поддерживают автодополнение как пространств документа, так и самих имён элементов (или их атрибутов, в расширенном виде, разумеется). Касаемо размера таких XML: XML Binary compression или обычное GZ-сжатие поможет уменьшить размер XML.

Говоря о процессе документирования XML Namespaces, то если вы читали статью, заметили, что те самые связки с URI в XMLNS и можно использовать для описания тех или иных элементов. Причём, это ещё и говорит о том, что важна правильная группировка элементов, с помощью которой вы получите такое их логическое разделение, что их будет удобно использовать в дальнейшем. Комментирование некоторых узлов документа в случае применения пространств имён позволит в дальнейшем сгенерировать довольно полную документацию по конкретному пространству и его элементам (атрибутам).

Интересное предложение. Однако, вы представьте, как будет выглядеть парсинг ваших документов, когда в первом из них лежат все имена в разбросе? Вам во втором документе придётся указывать не просто имена элементов и соответствующие им пространства, а использовать хотя бы XPath для выделения пересечений элементов. В таком случае, проще взять какой-нибудь формат-производную от XML, например XML Schema. Но обработка (парсинг) всего этого будет довольно сложна (сложнее, чем аналогичная с XML Namespaces). 
 
Превращать XML в X# (если интересно, можете поискать) я бы не стал, так как обычный формат хранения и передачи данных абсолютно не предназначен для таких «страшных» вещей, для которых создавался RDF и OWL. ]]> </description>
	<author>din@mandatory.ru (Din Neville)</author>
	<category></category>
	<guid>http://enumerate.ru/entry/xml_namespaces#_1094</guid>
	<wfw:commentRss></wfw:commentRss>
	
</item>

<item>
	<title>Tenshi</title>
	<link>http://enumerate.ru/entry/xml_namespaces#_1090</link>
	<pubDate>Sun, 25 Jan 2009 09:37:54 +0600</pubDate>
	<description> <![CDATA[ в действительности пространства имён — это фигня, ибо:

1. в каждом файле приходится писать расшифровки префиксов, а порой они занимают прилично места и просто напрашиваются на вынос в отдельный файл.
2. нельзя создать вложенные пространства имён

я бы предпочёл такую схему: в xml-ке идёт нагромождение тэгов с любыми именами, а в отдельной «xml-аннотации» идёт указание эквивалентности между используемыми тут именами и глобальными идентификаторами.
например:

<code type="plain">
o:user  [является эземпляром]  http://example.org/common/#person
o:user  [является эземпляром]  http://example.org/common/#account
</code>


при этом person и account — это различные классы, но o:user является экземпляром их обоих.
да, это можно описать с помощью rdf+owl, но как-то там всё слишком сложно =(
а массовые переименовывания можно делать с помощью паттернов (квадратные скобки вместо угловых):
<code type="plain">
[triplet]
   [subject]xsl:[word]name[/word][/subject]
   [relation]instanceOf[relation]
   [object]http://example.org/common/#[var]name[/var][object]
[/triplet]
</code>
такого rdf owl не умеют.

касательно практических примеров использования простанств имён в хтмл: http://d-o-b.ru/?article:kill.html ]]> </description>
	<author>din@mandatory.ru (Din Neville)</author>
	<category></category>
	<guid>http://enumerate.ru/entry/xml_namespaces#_1090</guid>
	<wfw:commentRss></wfw:commentRss>
	
</item>

<item>
	<title>Miscђka</title>
	<link>http://enumerate.ru/entry/xml_namespaces#_1089</link>
	<pubDate>Fri, 23 Jan 2009 14:29:07 +0600</pubDate>
	<description> <![CDATA[ Пространствовал по пространствам с удовольствием. ]]> </description>
	<author>din@mandatory.ru (Din Neville)</author>
	<category></category>
	<guid>http://enumerate.ru/entry/xml_namespaces#_1089</guid>
	<wfw:commentRss></wfw:commentRss>
	
</item>

<item>
	<title>Дин</title>
	<link>http://enumerate.ru/entry/xml_namespaces#_1088</link>
	<pubDate>Thu, 22 Jan 2009 14:33:16 +0600</pubDate>
	<description> <![CDATA[ @Kinder, рассказывать про пространства имён в XHTML нечего — их запрещено использовать в нём, а на основе XML приведён хоть и небольшой, но вполне ясный пример. XMLNS не такая тяжёлая тема, чтобы разбирать её на одних примерах, правда?

Хотя, если нужны какие-то конкретные примеры, то можете просить или приводить сами — будем вместе разбираться. ]]> </description>
	<author>din@mandatory.ru (Din Neville)</author>
	<category></category>
	<guid>http://enumerate.ru/entry/xml_namespaces#_1088</guid>
	<wfw:commentRss></wfw:commentRss>
	
</item>

<item>
	<title>kinder</title>
	<link>http://enumerate.ru/entry/xml_namespaces#_1087</link>
	<pubDate>Thu, 22 Jan 2009 12:47:26 +0600</pubDate>
	<description> <![CDATA[ Все же хотелось, увидеть больше примеров для использования пространств имен для xhtml, а то получился рассказ про фенечку, а как её применить, куда и для чего не ясно&#133; но заинтриговал это да =) ]]> </description>
	<author>din@mandatory.ru (Din Neville)</author>
	<category></category>
	<guid>http://enumerate.ru/entry/xml_namespaces#_1087</guid>
	<wfw:commentRss></wfw:commentRss>
	
</item>

<item>
	<title>Arwen</title>
	<link>http://enumerate.ru/entry/xml_namespaces#_1086</link>
	<pubDate>Thu, 22 Jan 2009 11:49:40 +0600</pubDate>
	<description> <![CDATA[ Да, девушки и правда в восторге. Спасибо за такое простое и доходчивое объяснение. Статья читается на одном духу. С почином постописательства в этом году. :) ]]> </description>
	<author>din@mandatory.ru (Din Neville)</author>
	<category></category>
	<guid>http://enumerate.ru/entry/xml_namespaces#_1086</guid>
	<wfw:commentRss></wfw:commentRss>
	
</item>


</channel>
</rss>

