XML Namespaces Don't Need URIs
by Michael DayApril 13, 2005
Background
In XML 1.0, element and attribute names were treated as atomic tokens with no interior structure.
Namespaces in XML introduced the concept of element and attribute names existing in namespaces. Namespaces are identified by URIs and bound to namespace prefixes. It is also possible to bind a default namespace to the empty prefix. This namespace will then apply to all elements that have no prefix.
For example, the XSLT elements exist in the
http://www.w3.org/1999/XSL/Transform
namespace, which is traditionally bound to the xsl namespace
prefix:
<xsl:transform xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
<xsl:variable name="foo" select="1"/>
...
</xsl:transform>
A namespace-aware XML processor will internally resolve these element names into tuples containing the namespace URI, the namespace prefix, and the local name:
{ http://www.w3.org/1999/XSL/Transform, xsl, transform }
{ http://www.w3.org/1999/XSL/Transform, xsl, variable }
The particular namespace prefix used is supposed to be irrelevant, but in practice people agree on common namespace prefixes for clarity, as it would be very confusing if everyone used different ones. Here are some familiar namespace prefixes from the W3C:
Prefix URI xmlhttp://www.w3.org/XML/1998/namespacexslhttp://www.w3.org/1999/XSL/Transformfohttp://www.w3.org/1999/XSL/Formatxsdhttp://www.w3.org/2001/XMLSchemahtmlhttp://www.w3.org/1999/xhtmlsvghttp://www.w3.org/2000/svg
Looking at this list one might wonder why it should be necessary to specify the namespace URI at all, considering that these namespaces already have a standard prefix that is far more concise and easy to remember. Using URIs to identify namespaces is a problematic approach with many usability flaws, all of which would be solved if namespaces were identified by the namespace prefix instead.
|
Related Reading 
|
What Is Wrong with Namespace URIs?
Let's look at three problems associated with namespace URIs.Namespace URIs Have Terrible Syntax
As seen in the table above, namespace URIs tend to be long and cryptic, with
lots of punctuation and case-sensitive text.
In this instance the W3C has compounded the problem by adding dates
to ensure that the namespace URIs are unique, as if it were likely that
the W3C would create another "XSL/Transform" or
"xhtml" namespace in the future.
While namespace URIs may be guaranteed to be unique, they are also
guaranteed to be impossible to remember. Quick, without checking, can you
remember if the namespace URI for W3C XML Schema ends with
"xmlschema", "XML/Schema", or
"XMLSchema"? Was the namespace URI for SVG allocated in 1999,
2000, or 2001?
The opaque nature of these namespace URIs is inconvenient for users, who must begin each new XML document with a ritual of carefully copying and pasting all of the namespace declarations from the last document that they were working on. If the namespace URIs are typed slightly wrong, the XML document will lose its intended meaning and software will fail to process it
.HTTP URIs Are a Poor Choice for Namespaces
HTTP URIs are often used as namespace URIs. However, most software treats HTTP URIs as resource locators, not identifiers. For example, the requirement to type namespace URIs exactly as they appear is at odds with the standard practice for HTTP URIs, which usually have many equivalent forms:
http://w3.org/1999/XSL/Transform
http://www.w3c.org/1999/XSL/Transform
http://www.w3.org/1999/XSL//Transform
http://www.w3.org:80/1999/XSL/Transform
http://www.w3.org/1999/XSL/Transform
All of these HTTP URIs will return the same web page if entered into a browser, but only the last one is the correct namespace URI for XSLT. This clashes with user expectations, to put it mildly. The one potential advantage of using HTTP URIs would be that they could act as links to useful resources, but in practice most people don't bother doing this. This disinterest is most strikingly observed with the XSLT and XSL-FO namespaces, which point to brief documents saying "Someday a schema for XSL Transforms will live here" and "This is another XSL namespace" respectively.
There was an effort to develop RDDL (Resource Directory Description Language) expressly for creating documents to sit at the end of HTTP namespace URIs and direct XML tools to associated resources such as style sheets, schemas, and documentation. It is not used by any tools on the Web and with good reason: there are better ways to associate resources with individual XML documents.
Aside: Why were URIs chosen over better alternatives?
It is not difficult to construct a better syntax than HTTP URIs for unique identifiers. A good existing example is the syntax used to identify Java packages:
org.w3.xsl.transform
Look at the difference. The identifier is all lowercase to make it easier
to remember, the redundant http://www. that
wastes the first 11 characters of so many namespace URIs is gone, as are
all the slashes.
Given that Java predated the XML Namespaces specification, one can only assume that URIs were chosen to identify namespaces for reasons other than syntactical convenience, such as their intended use in the RDF/XML syntax.
Namespace URIs Don't Help People Read or Write XML
Namespace URIs give people the ability to write XML documents with
arbitrary prefixes like <foo:schema> or
<superluminal:transform>, but people don't do that,
sensibly enough, as it would be confusing and serve no purpose. Since
people are already identifying namespaces using sensible namespace
prefixes, having to write the namespace URIs as well is just a hindrance.
Namespace URIs don't help people to read XML documents either.
They add an unnecessary level of indirection that makes XML documents
harder to interpret, as looking at an element name is no longer enough
to tell you exactly what that element is.
When you read an XML document beginning with
<html>, or <svg>, or
<xsl:transform>, or <xsd:schema>,
should it really be necessary to carefully check that the namespace prefix
is bound to the correct namespace URI?
Since namespace URIs don't help people to read or write XML documents, why should XML tools complain if they are omitted? Namespace URIs do not fit in with the goals of XML, which has been designed to be produced and/or consumed by people as well as software.
Could Namespaces Work Without URIs?
If namespace URIs were removed and namespaces were identified solely by namespace prefixes instead, namespaces would still make sense and existing XML specifications would only require minor alterations.
XSLT Without Namespace URIs
XSLT is one of the few XML languages that actually relies on namespaces for disambiguation, specifically to distinguish XSLT elements that are processed specially from other elements, which are output verbatim. XSLT also has the requirement to perform namespace rewriting in order to be able to output elements that are in the XSLT namespace without actively processing them, similar to quoting or escaping in other programming languages.
However, XSLT has no need for namespace URIs. An XSLT processor could instead
treat any element with an xsl prefix as being in the XSLT
namespace and process it accordingly. Elements with a different prefix or no
prefix would be output verbatim in the usual manner, and namespace prefix
rewriting would also take place as normal using the existing XSLT
aliasing mechanism:
<xsl:namespace-alias stylesheet-prefix="axsl" result-prefix="xsl"/>
Removing all of the namespace URIs from an XSLT transform will make it easier to read and write but will not affect the way it is processed, so why require namespace URIs for XSLT?
XHTML Without Namespace URIs
XHTML documents rarely use namespace prefixes, as many web browsers are
not XML-aware and do not expect to see them. In any case, a root element
of <html> should be sufficient to identify an XHTML document;
there is no pressing need to add the namespace URI as well.
Current W3C practice encourages XHTML documents to accumulate the namespace URIs
for XHTML, SVG, MathML, XForms, XML Schema, XML Events, and who knows what else.
All of these have simple prefixes that are sufficient to identify the
namespace in question, so there is no reason to place this burden on users.
XHTML does not need namespace URIs.
RDF/XML Without Namespace URIs
RDF/XML, the XML syntax for RDF that seems to have been the driving force for the adoption of namespace URIs, does not need namespace URIs. Or to be more accurate, it would be trivial to define a method of binding URIs to namespace prefixes specifically for RDF/XML, without forcing it to be a standard that applied to all XML documents. Given that RDF/XML is not an ideal syntax for representing RDF anyway—there exist numerous superior alternatives—-it is unfortunate that it has imposed such a clumsy namespace mechanism on the wider XML community.
The Default Namespace
There are some occasions such as modular XHTML, where people may wish to
write elements without namespace prefixes that are nonetheless in a
namespace. This could be done with an attribute like xmlns;
let's call it xml:ns, just for fun:
<blockquote xml:ns="html">
...
</blockquote>
An explicit namespace prefix is probably a better choice though, as it makes each element stand alone, with a fixed meaning that cannot be changed at the whim of its ancestors.
QNames in Text Content
One of the uglier architectural warts that namespaces has introduced to XML is the use of qualified names in text content:
<foo:message status="foo:severe" ...
The problem, of course, is that according to the current specification of XML Namespaces, namespace prefixes are supposed to be irrelevant and may be changed without altering the meaning of the document. Unless it uses namespace prefixes in text content, in which case the namespace prefixes become very significant indeed. Why not just drop the URIs, admit that the namespace prefixes are significant, and end the whole pointless charade?
Further Reading
|
Conclusion
For XML, it may already be too late to remove namespace URIs. While the XML specification itself does not depend on them, enough implementations already do so that it may be impractical to effect a change. However, there are still steps that can be taken when designing XML vocabularies to minimize the problems that namespace URIs cause:
-
Carefully consider whether namespaces are really necessary. Many XML vocabularies don't need them, so don't feel compelled to use them without good reason.
-
If namespaces are necessary, choose namespace URIs that are concise and easy to remember. It helps if they are all lowercase and don't include unnecessary information.
-
Try to get by with only one namespace if you can. There is not much to gain by multiplying namespaces unnecessarily except trouble and complexity. If you must use more than one namespace, at least ensure that the namespace URIs follow a consistent pattern.
-
Agree on standard namespace prefixes for your XML vocabularies; they will help people to read and write your XML without confusion. If you find yourself using the default namespace rather than the prefixes, consider whether you actually need a namespace at all.
Following these steps will help to keep namespace URIs under control in your XML documents.
Share your experience in our forums.
(* You must be a member of XML.com to use this feature.)
Comment on this Article
| Titles Only | Titles Only | Newest First |
- Namespaces themselves were a mistake.
2008-05-14 02:25:29 MartinBriley [Reply]
Great points in your essay. But take it to the next level: Namespaces were a dumb mistake to begin with, totally disregarding the fact that elements can be identified by the context in which they appear.
If the entire structure needs identification, it can use an element at the top as a type identifier.
And from there we could get to elements vs. attributes...
XML, as often implemented, is just a mess. It could have been so clean and simple, but of course somebody screwed it up.
- Misdirected complaints
2005-04-23 17:21:07 afettes [Reply]
Hi Mike,
Three points:
1. In the past I have found it very useful to copy/paste that annoying URI into my web browser. A thoughtful developer/organisation will put up information regarding their specification at that location. This is very useful symantic information. Removing the URI removes this potential. This was presented by Tim Bray at a talk a couple of years ago in Vancouver (http://www.vanx.org) as "good practice"; I whole heartedly agree with this statement.
2. I do believe that you are misdirecting your criticism. If you feel that certain URIs are long and hard to remember, maybe you should direct this complaint at the organization that created that URI? As an XML language author you have full control on exactly what your URI will look like. Not every XML document conforms to a W3C specification...
3. Your point about the W3C not releasing a second specification of a particular language is moot. SVG 1.2 is currently in the works. In this case, both languages will have a root element of <svg/>. However, there will be large additions to the language from SVG 1.1 to SVG 1.2. Technologies such as sXBL will have significant ramifications as to how SVG viewers will interpret the graphic.
Cheers,
Alastair
- Misdirected complaints
2005-04-23 19:54:03 mikeday [Reply]
Hi Alastair,
Your first point about the documentation aspects of namespace URIs is reasonable, but I am not sure that it outweighs the inconvenience of namespace URIs. I think that Google is a more convenient method of finding documentation, myself.
It is true that the examples I criticised were all from the W3C, as those namespace URIs are more widely known and used. However, the problems are not specific to the W3C's choice of URIs. The choice of URIs as a syntax and the emphasis on globally unique names is the problem.
The point about SVG actually reinforces what I was saying: the new version of SVG still uses the same namespace as the old version, as the semantics of most elements has not changed. It would be odd indeed for the W3C to create a new XML language called "SVG" with entirely different semantics to the existing one. That would justify, or in fact require, a new namespace, but no one would ever do something so confusing. (Um, the example of RSS proliferation might prove me wrong here :)
- Misdirected complaints
2005-05-09 09:06:08 afettes [Reply]
Hi Mike,
Here are my rebuttals:
1. Truth does not always lie in Google. What happens if that google bot has not cached the required document? What about if the document is in a intranet that is not open to the famed google bot? The company I work for is massive and may define a large number of XML documents, each with a local *intranet* defined URI describing the schema.
2. I'm not sure why having globally unique names is a bad thing? I feel it is a great thing. It could be deemed similar to DNS or a tangible housing addresses (postal code, etc). Once again to that intranet defined language. Say my languages are defined as follows:
"http://language1.mydomain.com/v1"
"http://language2.mydomain.com/v5"
These do not seem so complicated. They are descriptive, locally accessible though not google-able, and easy to use and remember.
3. True that the syntax for many elements have not changed. However, some have. A perfect example is the text element. In SVG 1.2 the text element has an attribute editable. If this is set to true, then the user can edit the text as in a text input box. This is not available in SVG 1.1. Therefore if the SVG is labelled as SVG 1.1 then there is no text editing capabilities and thus must be treated differently from SVG 1.2. This distinct difference requires some method of specifying exactly which version the source document is written in. Hence the use of a namespace (with the same prefix of course as it is still SVG).
I feel that a good contribution that your article could have made would be of forming a standard way of addressing URIs in namespaces. Similar to coding standards in C++ or Java. Show a best practices. I would find that very useful.
Cheers,
Alastair
- Misdirected complaints
- Misdirected complaints
- That won't work
2005-04-19 02:44:13 olegtkachenko [Reply]
That won't work. People are using both xs and xsd prefixes for XML Schema for years now.
And removing namespace URIs would just just shift the uniqness requirement to prefixes, which would lead to ugly lengthy ones.
- That won't work
2005-04-19 03:01:51 mikeday [Reply]
I think it is worth considering alternative methods for disambiguation that do not require giving every element a globally unique name, which in most cases is overkill.
For example, why not use a regular attribute on the root element to identify the "type" of the document, but without needing to propagate that attribute down to the child elements like a namespace. That would allow disambiguation while eliminating the scoping issues.
The different approaches taken to versioning by XSLT 2.0 and XHTML 2.0 are an interesting example. XSLT has a version attribute and keeps the same namespace, while XHTML 2.0 is in an entirely different namespace, even though most of the elements are identical to those in XHTML 1.0.
I think that the approach taken by XSLT is more practical, but as I show in the article XSLT can get by quite happily without any namespace at all. The namespace is only necessary for a process which accepts many different kinds of XML documents whose root element is <xsl:stylesheet> or <xsl:transform> and needs to disambiguate them -- does such a process exist?
- That won't work
2005-04-27 08:31:06 EdSaltelli [Reply]
"For example, why not use a regular attribute on the root element to identify the "type" of the document, but without needing to propagate that attribute down to the child elements like a namespace. That would allow disambiguation while eliminating the scoping issues."
This is possible today with the proper Schema definitions and attributes. By defining only one top level element and using setting the schema attribute elementFormDefault='unqualified'. All other elements would be defined w/in the scope of the global element; the default serialization of your XML document would not require all of the namespace prefixes on the elements.
- That won't work
- That won't work
- Updated namespace URIs "likely"?
2005-04-15 19:52:11 Jelks Cabaniss [Reply]
"...W3C has compounded the problem by adding dates to ensure that the namespace URIs are unique, as if it were likely that the W3C would create another "XSL/Transform" or "xhtml" namespace in the future."
Well, they're proposing to do exactly that with XHTML 2.0. As of the latest draft (which is, granted, almost a year old), the namespace for 2.0 is:
http://www.w3.org/2002/06/xhtml2
(Check out "Conformance Definition" in the WD spec.)
And so it goes, on and on and no. The Energizer Funny.
- Updated namespace URIs "likely"?
2005-04-15 20:33:26 mikeday [Reply]
Hi Jelks,
Thanks for picking that up! It seems that I have misunderestimated the ingenuity of the HTML working group.
It is amusing to note that the example XHTML 2.0 document given in the Conformance Definition would be a perfectly valid XHTML 1.0 document also, if it wasn't for the different namespace. Truly an odd decision.
But then again, mandating an xsi:schemaLocation on the root element is also very odd, given that XHTML 2.0 is supposed to be extensible, which would argue against a fixed schema.
However, I would argue that the dates in the namespace URIs are still unnecessary, as the XHTML 1.0 namespace has "xhtml" while the XHTML 2.0 namespace has "xhtml2". These are sufficiently different without adding dates as well.
Best regards,
Michael
- Updated namespace URIs "likely"?
- Why and how this should be implemented immediately
2005-04-15 18:27:40 fuzzyBSc [Reply]
Why?
This bug: http://www.mail-archive.com/xalan-dev@xml.apache.org/msg23493.html
The bug appears in jdk 1.5.0. The design decision to make qname prefixes reassignable remains a major problem for tool correctness.
How?
If you are going to drop the current opacity of qname prefixes such as xsl and go to a java package naming scheme you also need a "uses" statement. com.w3.xsl would be cumbersome to type everwhere, so all or part of the namespace must become implicit with either a "using com.w3" or using "com.w3.xsl" statement.
We can't do this in a straightforward way with attributes because attributes can't be repeated. <Foo xml:uses="com.w3" xml:uses="com.example"/> will not work. Sub-elements aren't good unless they apply to their parent node (otherwise there wouldn't be a way to assign namespaces to the root node of your document).
Is the sub-element applying to parent element the best approach?
Benjamin.
- URI is not a URL
2005-04-15 12:05:37 RobertField [Reply]
Besides URLs, it is possible to use URNs, which would look like urn:namespace:extrastuff. This is subject to all the problems of elaborate complexity, as in
urn:somedomain_veryimportantschema:2005.v249
but have the advantage, to my thinking, of not looking like a regular web address, which was a source of early confusion to me, and I suppose many others. It took a while to realize the URI was simply an inert placeholder and was not the source of some information.
As for "well known" schemas, what happens when I get a piece of XML from Silicon Valley Groundhog Supply, with root element <svg>, that happens to have some SVG embedded. I know it's a little far fetched, but the major point of namespaces is to avoid having to select unique names for elements, by having the namespace to enclose a specific group of them.
- URI is not a URL
2005-04-15 17:57:05 mikeday [Reply]
Yes, URNs do reduce some of the problems associated with using HTTP URLs to identify namespaces, although as you point out they are still rather complex.
Your example of the Silicon Valley Groundhogs is interesting, but not an argument for namespaces. If you have an established relationship with the groundhogs people then receiving an XML document (either by email or a HTTP POST) with a root element of <svg> will not surprise you.
If within that document there is an embedded image:
<groundhog>
<name>Grumpy Groundhog</name>
<picture>
<svg>...</svg>
</picture>
</groundhog>
that should not surprise you either, as the context is sufficient to tell that it is an image.
Ambiguity is only possible if there were two XML image formats with a root element of <svg>, or two transformation languages that used <xsl:transform>.
This case is much less likely, and there are more gentle ways to disambiguate it than mandating namespace URIs everywhere.
- URI is not a URL
2005-04-16 03:36:18 bryan rasmussen [Reply]
the document element of xsl-fo is root.
It may be unlikely that two pagination formats will have a document element root, but certainly possible. It is highly likely that a generic xml handling solution will have to deal with many different formats which have root as the document element.
- URI is not a URL
2005-04-16 03:58:26 mikeday [Reply]
XSL-FO is not a compelling argument for namespaces, given that XSL-FO documents are generally fed directly into programs expecting XSL-FO, with no need for disambiguation.
One could imagine two different markup languages both having a root element of <fo:root>, and a formatter that supported both markup languages, and yet such a thing does not exist.
Namespaces on the other hand do exist, apparently to solve non-existent problems, while causing real problems of their own.
- URI is not a URL
- URI is not a URL
- URI is not a URL
- Namespace prefix registry
2005-04-14 17:01:14 mikeday [Reply]
Hi Bryan,
I did not mention the idea of a namespace prefix registry in the article because I don't believe that such a thing would be necessary -- it certainly would not be very practical to implement.
The example I gave of using XSLT with namespace prefixes and no namespace URIs does not need a namespace registry in order for the XSLT processor to function correctly, which is worth keeping in mind.
I think that the perceived need for a namespace registry and for unique namespace URIs is based on the misconception that every element name must be globally unique in every circumstance or software won't know what to do.
In practice, XML processing software usually has more contextual information available to it than just the element names, and disambiguation can be based on context, position, attributes and so on rather than making names globally unique.
Best regards,
Michael
- Namespace prefix registry
2005-04-15 06:08:15 bryan rasmussen [Reply]
I'm not sure what you mean by this, if you mean that prefixes should have a hardcoded association then obviously you could not maintain that for every namespace, so you would just want to do it for the important namespaces (I suppose that is a reasonable way of defining these namespaces you refer to in the article) some problems arise
1. parsers must now support a list of prefixes that don't need to have a namespace associated with them. how does one make sure that parsers maintain the same list
2. people will be fighting to get their namespace on the list of important namespaces
3. one of the problems with namespaces is that they confuse newbies, the idea of having pre-established prefixes and then prefixes that are not pre-established would be highly confusing in itself.
4. If the idea is not to have a list then I guess you're just saying that there is no need for namespacing whatsoever. I could agree with that in relation to the scenario for their usage put forward in the spec but not in the context of how they are actually used.
- Namespace prefix registry
2005-04-15 17:50:36 mikeday [Reply]
No, I don't think parsers have any need at all for a list of prefixes or any hard-coded associations.
The examples I gave of a web browser recognising <html> or an XSLT processor recognising <xsl:transform> do not require the parser to do anything with prefixes and do not require a list of important namespaces.
So I would agree with your point 4., that there is essentially no need for namespaces whatsoever, given the current meaning of the term. As to "how they are actually used", surely the XSLT use of namespaces is one of the most widely used; that was why I chose to discuss it.
I would be interested in counter-examples from actual real use cases, though, as so far I have only seen hypothetical ones.
- Namespace prefix registry
2005-04-16 03:29:58 bryan rasmussen [Reply]
The actual use of namespaces, as opposed to the stated reason for their existence and predating XML Schema which has a bad model for this usage of namespaces, is to allow the extensibility of applications with data not understood by a particular application X but understandable by a particular application Y or some developer's homemade script for example. This takes advantage of the general habit of applications targetting various xml dialects of ignoring what they do not understand in an unknown namespace (xhtml, svg, xsl-fo) certainly this could be done without using namespaces but would lead to other problems vis-a-vis validation. Also there are certain xml formats such as XMI or the xml serialization of RDF that can be considered as helper formats, these formats also happen to have names of both elements and attributes that could give rise to name collisions (Description springs immediately to mind), one could get around this problem by making sure one gave all elements and attributes unlikely to be duplicated names, such as RDFDescription but that would just add to the ugliness of syntax in another way than namespaces and would probably lead to confusion from newbies anyway (as in why don't we just call it Description?!?), to get around this problem somebody somewhere would probably then suggest that we need namespaces.
I made the mention of XML Schema because as noted it has a bad model for this usage of namespaces, so as to build extensibility into the validation of xml schema one often uses the any construction at various places, which can be used to associate extensible content with specific namespaces and so forth. This indicates another little useful aspect of namespaces for programming in that namespaces allow one to refer to sets of elements and attributes generically, for example the xpath //html:* would allow you to get all xhtml elements given that you had associated with the namespace, this can of course also be done in other APIs to XML, this is a real time saver. I can think of other ways this could be done, but these ways would be far from trivial, if you can think of a trivial way to do it please point it out, and I should think the way should be described somewhat concretely.
This facility of mixing namespaces is of course very important to the concept of compound documents.
- Namespace prefix registry
- Namespace prefix registry
- Namespace prefix registry
- Look for the pain
2005-04-14 14:08:27 Micah Dubinko [Reply]
When's the last time you've heard anyone complain about how Java Namespaces are implemented?
I don't think I've ever heard that complaint! It would have been a good system to follow.
More here soon...
- the real problem with namespaces and dereferenceability
2005-04-14 10:50:01 bryan rasmussen [Reply]
The problem is that a uri has parts that are not relevant to determining the location of a resource, it would have been nice to have this same facility in namespaces, especially in cases where we want our namespaces to be dereferenceable.
Thus an uri http://www.w3.org/2001/XMLSchema#related.resources
would be considered as the same namespace as http://www.w3.org/2001/XMLSchema
But that is another thing that is not getting fixed anytime soon.
P.S: Don't you find it ironic that one of the namespaces you spent so much time complaining about has a rddl document at the end of its dereferenceable uri?
- the real problem with namespaces and dereferenceability
2005-04-14 10:51:25 bryan rasmussen [Reply]
okay I'm gonna stop commenting on this article, there were just a number of points that somewhat rubbed me the wrong way.
- the real problem with namespaces and dereferenceability
- somewhat amusing
2005-04-14 10:35:38 bryan rasmussen [Reply]
that this article is being published now when it looks like a round of discussion is being started up with good arguments for always using uris
http://www.pacificspirit.com/blog/2005/04/11/why_http_uris_are_better_than_urns_and_even_id_uris_for_identifiers
http://seanmcgrath.blogspot.com/2005_04_10_seanmcgrath_archive.html#111337910941603816
- Not so fast...
2005-04-14 10:23:45 ejain [Reply]
You need to be real careful here that you don't complicate things while trying to simplify.
Let's say I create a simple XML-based format for a small project I am working on. I decide to create a namespace for my elements, perhaps because I want to reuse elements from other schemas, or I want to encourage others to reuse or embed elements from my schema.
Now I'll either have to choose three meter long prefixes to ensure that there won't be any conflicts with future prefixes (or currently used prefixes I am not aware of).
A more reliable approach would be to have some kind of registry system. But such a thing could take years and tons of money to set up and gain legitimacy. And people may start asking why go through all this trouble, when there already is a solution that reuses existing infrastructure (i.e. the domain name system; I bet that wasn't cheap to set up :-)
Besides, after a year or two you wouldn't be able to get any easy to remember prefixes with less than five letters...
An unrelated comment: If you really don't like using URLs as namespace identifiers, you can use URNs.
- where to start
2005-04-14 06:29:51 bryan rasmussen [Reply]
This argument boils up now and again, it is one of the great xml-dev permathreads (that namespace uris are a mistake) and as such should be presented to beginners in the xml world for their enlightenment. That said this article is probably not a good introduction to the matter because it seems highly inaccurate (I say seems being mindful of the fact that I myself may be mistaken on matters.)
Areas where I take exception with this article are as follows:
1. The statement "Using URIs to identify namespaces is a problematic approach with many usability flaws, all of which would be solved if namespaces were identified by the namespace prefix instead." would be far more reasonable if you identified how the prefix should then be resolved for said prefixes? Would each parser be required to have a list of known prefixes, would the meaning of prefixes be determined by querying a registry of prefixes, or would it just be a weird element name.
2. without checking I remembered the namespace for XMLSchema, at any rate that namespace uris tend to be long and cryptic should prompt the question as to whether actual http uris tend to be long and cryptic.
3. "There was an effort to develop RDDL (Resource Directory Description Language) expressly for creating documents to sit at the end of HTTP namespace URIs and direct XML tools to associated resources such as style sheets, schemas, and documentation. It is not used by any tools on the Web and with good reason: there are better ways to associate resources with individual XML documents." Although I would certainly agree that there is not much RDDL usage there is indeed some, as usual xml.coverpages has a nice listing of relevant rddl resources http://xml.coverpages.org/rddl.html some of which point to rddl sites. It should also be noted that there are RDDL modules for popular programming languages php and perl that I am aware of, and of course XSV uses RDDL to derive the location of a schema for a namespace if it does not have one to use.
4.
"Namespace URIs give people the ability to write XML documents with arbitrary prefixes like <foo:schema> or <superluminal:transform>, but people don't do that, sensibly enough, as it would be confusing and serve no purpose."
well no, but people sometimes do do <s:schema> or <x:transform> because they find that quicker than <xsd:schema> or <xsl:transform>, and generally the ones that do are the more advanced users.
5.
"RDF/XML, the XML syntax for RDF that seems to have been the driving force for the adoption of namespace URIs, does not need namespace URIs"
I don't know where you get this theory, the three guys on the xml namespaces rec. Tim Bray (Textuality) <tbray@textuality.com>
Dave Hollander (Hewlett-Packard Company) <dmh@corp.hp.com>
Andrew Layman (Microsoft) <andrewl@microsoft.com> are not widely known for their association with RDF, Tim Bray could be considered an RDF skeptic http://www.tbray.org/ongoing/When/200x/2003/05/21/RDFNet (in fact it is recent essays like this that caused me to forget he ever was associated with RDF at all), Microsoft does not seem to like RDF, so why the hell did they work on this thing if it had to do with RDF. There was no mention of RDF in the spec, in Namespaces for XML 1.1 there was no mention of RDF. Maybe it didn't mention it in the first spec because it was released a month before the RDF specs, but in the second spec? Hmm, maybe they just didn't mention it in the second spec because they don't care about RDF. Which means that probably their intentions for having namespaces are those outline in the spec, which in no way mention RDF. I am perhaps wrong about this, but given the lack of a mention for RDF in the namespaces specs I would like a reference for your claim that namespaces were made to support RDF/XML (especially given that RDF/XML was one possible serialization of RDF, and was given as an option at the time that the eventual success of XML was very much up in the air.)
6. "org.w3.xsl.transform" you can already name a namespace in this way, your article might lead the uninformed to assume that they couldn't
7. "Given that Java predated the XML Namespaces specification, one can only assume that URIs were chosen to identify namespaces for reasons other than syntactical convenience, such as their intended use in the RDF/XML syntax."
Or that URIs were already an identification scheme known to people and that held within them the possibility of using URNs http://www.w3.org/TR/uri-clarification/#uri-partitioning
8. "If namespace URIs were removed and namespaces were identified solely by namespace prefixes instead, namespaces would still make sense and existing XML specifications would only require minor alterations." This suggestion comes up every now and then, generally associated with a registry idea, a registry for various reasons can be problematic, please be specific as to how you wanted to solve this rather than just making pronouncements.
9."Why not just drop the URIs, admit that the namespace prefixes are significant, and end the whole pointless charade?
" followed immediately by "For XML, it may already be too late to remove namespace URIs. "
and a list of suggestions that I suppose may be helpful to someone somewhere, even if I am not exactly certain how they would be helpful.
Michael Day has a very nice product in YesLogic Prince, I would have appreciated more articles on printing in xml and printing technologies. But this article seems very poorly put together on an admittedly wide and problematic subject.
- where to start
2005-04-14 09:10:07 bryan rasmussen [Reply]
also as regards point four sometimes people do do just plain <schema xmlns="http://www.w3.org/2001/XMLSchema"> and so forth.
- where to start
2005-04-14 09:02:24 bryan rasmussen [Reply]
the statement ' Tim Bray could be considered an RDF skeptic' was of course out of temporal order, but nonetheless I've never thought of Tim Bray as a name one would immediately associate with RDF.
- where to start
- Non-locating URIs
2005-04-14 05:02:23 janegil [Reply]
"most software treats HTTP URIs as resource locators, not identifiers".
And that is a general problem, not limited to namespaces. No non-digital resources - be they abstract objects like namespaces, or physical objects like ships - can be identified by a URI that is also a URL. By definition, the object identified is the object located. (And the resource located by HTTP is always a digital one.)
Strictly speaking, namespaces are not really identified by a Universal Resource Identifier, they are identified by a namespace identifier that happens to have the same syntax as a HTTP-URL.
