Lists Home |
Date Index |
Jonathan Borden wrote:
> Note that the XML Namespaces recommendation states that XML namespaces _do_
> have internal structure (but does not specify what the structure is).
> Formally, a space may generally be described as a pair:
> <name, node*>
> (This can be pictured by drawing a rectangle around a piece of a graph and
> giving it a name)
> In the case of an XML Namespace:
> <nsURI, term*>
It's more complicated than that because of this:
> In the RDDL model, each term can be represented as the ID of the
> rddl:resource element -- in this case the set of rddl:resource elements
> defines a set of names.
The spec says only:
The id attribute value may be used to give the resource description a
How would I know reading the spec that these IDs are supposed to be
element type or attribute names? Also, how would I talk about an
attribute of an element where the attribute has no prefix.
And with all due respect to RDDL, the fundamental question of how to
combine namespaces is left un-addressed. So we've got the gravy but not
For example, I could argue that vocabulares which embed XHTML (like
RDDL) abuse it, or that XSLT does so when it uses XHTML elements as
literal result elements. If namespaces mean something beyond punctuation
then one or the other must be wrong.
I do know that I am miles away from a situation where: "a single XML
document may contain elements and attributes (here referred to as a
"markup vocabulary") that are defined for and used by multiple software
Sure, I can do this today if I have a priori knowledge of how the
namespaces combine in a *particular document*. But in general I cannot
pick out the HTML:title elements and do anything useful with them
because in an XSLT or SOAP context they mean something totally different
than in a RDDL context. And you certainly can't know what I mean by them
<foo:bar><html:title>Blah</html:title></foo:bar> (please assume
So I need a priori knowledge, transmitted out of band. But if I depend
upon information transmitted out of band then I could just as easily
have transmitted the information of how to map local names like HTML_P
to global names without the headache of namespace declarations and URIs.
This information could be transmitted using either a DTD with
architectural forms or a schema with schema derivation.
If namespace URIs are to be useful to machines then they should be
pointers to the machine-readable information necessary to interpret what
it means for one namespace to occur within another. Considering the
range of namespace (ab)uses available today, from SOAP to XSLT to RDDL,
I can't imagine what that resource would look like. This suggests to me
that it is safest to view namespaces as "just punctuation" and not try
to do software dispatching on them without out-of-band knowledge that
this actually works for the particular process you are trying to execute
and the particular document you are working with.
> Each term or ID is itself associated with the rddl:resource tuple:
> <id, nature, purpose, lang, href> 
>  http://www.openhealth.org/RDDL/rddl.extreme.xml
Connecting to www.openhealth.org:80... connected!
HTTP request sent, awaiting response... 404 Not Found
16:44:16 ERROR 404: Not Found.