OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Searchable Namespaces

Hi everyone,

Lately I've been reading up on the various ideas that have been floating 
around to improve namespaces (many of which were discussed on this 
mailing list) and I've noticed a few things:

1) Most of them aren't backwards compatible with contemporary namespaces.
2) Many of them are incompatible with current parsers, or require more 
context than XML parsers are currently required to handle.
3) When it comes to improving the authors' experience, some of them put 
*additional* workload on authors, and some of them don't do an adequate 
job of making namespaces easier to learn.

Well, I'm not an XML guru or anything, but I've worked with a fair 
amount of XML, including writing my own parsers, so this puzzle piqued 
my interest.

Attached is my attempt to crack this nut.  You'll probably notice a lot 
of influence from Ian Hickson's "search path" solution and Tim Bray's 
Java-style names.  You know what they say about the shoulders of giants :)

Anyway, let me know what you think.


1: Specification

1.1: Local names may include multiple colons.  Fully-qualified names 
should be in reversed-dns form, separated by colons.

Example 1.1.1:

1.2: xmlns and xmlns: attributes specify a list of namespaces separated 
by spaces.  e.g.:

Example 1.2.1:
<html xmlns="org:w3:xhtml5 org:w3:svg12">

Example 1.2.2:
<w3:html xmlns:w3="org:w3:xhtml5 org:w3:svg12">

1.3: Namespaces are hierarchical.

Example 1.3.1:
<xhtml5:html xmlns="org:w3">

1.4: Old-style namespaces may still be used, but because they contain 
invalid characters, they must be used with an xmlns or xmlns: attribute.

Example 1.4.1:
<html xmlns="http://www.w3.org/1999/xhtml http://www.w3.org/2000/svg";>

Example 1.4.2:
<html xmlns="http://www.w3.org/1999/xhtml org:w3:svg12">

Example 1.4.3:
<html xmlns="http://www.w3.org/1999/xhtml";>

1.5: Children that define a default namespace automatically include 
their parent's default namespace.  The following two examples are identical:

Example 1.5.1:
<html xmlns="org:w3:xhtml5">
		<svg xmlns="org:w3:svg12">...</svg>

Example 1.5.2:
		<svg xmlns="org:w3:svg12 org:w3:xhtml5">...</svg>

2: Implementation

2.1: Non-namespace-aware parsers should ignore everything before the 
*last* colon.  This should also be the case for non-namespace-aware 
languages, such as CSS2.

2.2: Contemporary namespace-aware parsers typically provide the user 
with three pieces of data for every XML name: the local name, the 
prefix, and the namespace.

2.2.1: Namespace-aware parsers must first check to see if the first part 
of the XML name was previously specified in an xmlns: attribute.  If so, 
the first part is saved as the prefix, the remainder is saved as the 
local name, and the space-separated namespace list specified by the 
xmlns: attribute is saved as the namespace.

For instance, the 'svg' tag in example 1.2.2 would be parsed as such:

local: "svg"
prefix: "w3"
namespace: "org:w3:xhtml5 org:w3:svg12"

2.2.2: If the XML name did not specifiy a prefix, then the entire XML 
name is saved as the local name, and the default namespace is saved as 
the namespace.

For instance, the 'svg' tag in example 1.5.1 would be parsed as such:

local: "svg"
prefix: NULL
namespace: "org:w3:svg12 org:w3:xhtml5"

The 'svg' tag in example 1.3.1 would be parsed as such:

local: "svg12:svg"
prefix: NULL
namespace: "org:w3"

An XML file which is valid under the old-style namespace rules should be 
parsed identically using these new rules.

2.3: A simple function can be written to compare a fully-qualified XML 
name against the local, prefix, and namespace parts.

Example 2.3.1:
	"svg", NULL, "org:w3:svg12 org:w3:xhtml5"))
	// Do something.

(Note: implementations are of course free to store the namespace in a 
structure that's more efficient than a naive string.)

2.4: A more advanced implementation may want to specify a list of known 
tags, to allow for conflict resolution.  For orthogonal dialects, or 
dialects that are unambiguous in context, this is unnecessary.  This 
list is only needed by the software that knows what each tag means; any 
parsing step that happened earlier can blissfully ignore conflicts.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS