SVG中国

文章首页
XML Namespace命名空间上手指南
什么是命名空间(Namespace)
XML为什么需要命名空间?
XML命名空间的语法规则
解析器是怎样处理XML命名空间的?
命名空间和DTD
命名空间和XML模式

　　一些文件兼有来自于不同XML应用的标记。例如，XHTML文件可能含有SVG图片和MathML方程式。XSLT样规（stylesheet）包含了XSLT指令和来自于结果树字彙的元素。XLink则总是和它们所出现之文件的元素共生，因为XLink本身只定义属性，而未定义任何元素。

　　在某些情形下，这些应用可能使用同样的名称，来代表不同的事物。例如，SVG中的set元素是个抽象的容器，用来赋予一群元素一个共通特性；而MathML中的set元素，则代表了一个数学上的集合，例如所有正偶数之集合。你应清楚何时该用MathML的set，而何时又该使用SVG的set，否则正确合法的验证、呈现、索引以及许多其它工作，可能会因受到混淆而失败。
　　请考虑范例1。这份范例是个简单的绘画作品清单，包含了每幅画的名称、画家、作画日期，以及一些简单的描述：

范例1：代码清单。

<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<catalog>
　<painting>
　　<title>Memory of the Garden at Etten</title>
　　<artist>Vincent Van Gogh</artist>
　　<date>November, 1888</date>
　　<description>
　　　Two women look to the left. A third works in her garden.
　　</description>
　</painting>

　<painting>
　　<title>The Swing</title>
　　<artist>Pierre-Auguste Renoir</artist>
　　<date>1876</date>
　　<description>
　　　A young girl on a swing. Two men and a toddler watch.
　　</description>
　</painting>
　<!-还有更多代码... -->
</catalog>

　　现在假设范例1将会以web网页的形式被提供，而你希望它能被搜寻引擎存取。一种可能的方法是：使用资源描述框架（Resource Description Framework，RDF），将metadata嵌入此网页中。如此描述该网页，以利任何搜寻引擎或网路爬虫的工作。使用Dublin Coremetadata字彙（http://purl.oclc.org/dc/）─它是一种图书编目分类资讯所使用的标准字彙，并且可以用XML或其它的语法来编码─那么这个网页的RDF描述会如下：

<RDF>
　<Description about="http://ibiblio.org/examples/impressionists.xml">
　　<title> Impressionist Paintings </dc:title>
　　<creator> Elliotte Rusty Harold </creator>
　　<description>
　　　A list of famous impressionist paintings organized
　　　by painter and date
　　</description>
　　<date>2000-08-22</date>
　</Description>
</RDF>

　　此处我们使用RDF中的Description和RDF元素以及Dublin Core的元素：title、creator、description和date。我们无法选择要不要使用这些名称，因为它们已被建立于各自的规格中。如果我们想要一个能读懂RDF和Dublib Core的标准软体，且能读懂我们的文件，那么就必须使用这些名称。范例2将这份描述和真正的代码清单结合。

　范例2：一份代码清单，包含了关于清单的编目资讯。

<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?>
<catalog>
　<RDF>
　　<Description
　　　　about="http://ibiblio.org/examples/impressionists.xml">
　　　<title> Impressionist Paintings </title>
　　　<creator> Elliotte Rusty Harold </creator>
　　　<description>
　　　A list of famous impressionist paintings organized
　　　by painter and date
　　</description>
　　<date>2000-08-22</date>
　</Description>
　</RDF>

　<painting>
　　<title>Memory of the Garden at Etten</title>
　　<artist>Vincent Van Gogh</artist>
　　<date>November, 1888</date>
　　<description>
　　　Two women look to the left. A third works in her garden.
　　</description>
　</painting>

　<painting>
　　<title>The Swing</title>
　　<artist>Pierre-Auguste Renoir</artist>
　　<date>1876</date>
　　<description>
　　A young girl on a swing. Two men and a toddler watch.
　　</description>
　</painting>

　<!-还有更多代码... -->

</catalog>

　　现在我们发现一个问题。好几个元素被重覆使用于文件的不同部份，来代表不同的意义。title元素用来作为整个网页的标题，也用作表示代码的标题。date元素则被用来表示网页製作的日期和作画的日期。description元素的其中一个描述了整个网页，而另一个则用以描述代码。

　　这种情形造成了各种问题。由于具有相同名称的catalog和Dublin Core元素会有不同的内容模型，使得正确合法性的验证变得困难。对网页浏览器而言，显示代码的叙述时，你可能希望隐藏网页的叙述部份，但并非所有的样规语言都能分辨这两者。处理软体可能看得懂Dublin Core的date元素之日期格式，却无法了解代码中date元素的日期格式。

　　我们可以改变元素名称，例如，使用painting_title来代替title，使用date_painted代替date，等等。但是，如果有一大堆文件已经用旧的字彙来标记，要将它们全换成新版本的字彙可不是件容易的事。更何况，若要将所有情况都做这种改变，也不太可能，特别是当名称冲突发生在两三种标准字彙之间，而不光只在你自定的字彙与某种标准字彙之间时。比方说，RDF就几乎无法避免使用和DublinCore元素相同的名称，像是Description和description。

　　在其它状况下，名称冲突可能不会发生，但是它对于想快速、果断地决定某个元素或属性是属于哪种XML应用的软体，仍然十分重要。例如，一个XSLT处理器必须分辨XSLT指令和文字化的结果树元素。