38

Take this line as just one example:

<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
</configuration>

Some brief research has taught me that nothing necessarily has to be hosted at that URL. Therefore, if it's just a reference to a namespace contained in a local assembly, why use URLs instead of regular namespaces like the ones typically used by .NET (System.Data, for example)?

John Saunders
  • 157,405
  • 24
  • 229
  • 388
oscilatingcretin
  • 9,495
  • 31
  • 111
  • 188

4 Answers4

17

When you ask why a standard is the way it is, there are two possible interpretations of your question: (a) what are the perceived benefits of the design choice that was made, and (b) what was the historical sequence of events that led to this design being adopted over other designs.

Clearly, using HTTP-like URIs gives uniqueness. But that could also have been achieved in other ways, for example by inventing a new URI scheme. I think that if you trace the arguments that were made at the time, you will find that many of the people advocating the use of HTTP-style URIs were also advocating that namespace URIs should be dereferencable, perhaps to a schema or to some other kind of document. Indeed, it's W3C policy for its own namespaces that there is always a document that can be retrieved when you type the namespace URI into a browser, and that it should tell you something useful about the namespace.

So I suspect the fact that we use URIs that look deferenceable but don't define any semantics for what happens when they are dereferenced is in fact the result a committee compromise between two or more opposing camps. But you'd have to do some proper historical research to confirm that.

Michael Kay
  • 138,236
  • 10
  • 76
  • 143
12

It's just a convention. URIs (which is what they are, not really URLs) are a convenient and globally-familiar way of identifying resources. On the other hand, .NET-style identifiers are familiar and recognisable to, well, .NET developers - there's rather more to XML than .NET.

skaffman
  • 381,978
  • 94
  • 789
  • 754
  • 1
    Hopefully it really is globally-unique. Otherwise, there's not much point. – Robert Harvey Apr 22 '11 at 17:28
  • 2
    @Robert: I disagree. XML Namespace URIs need only be unique *in the context in which they are used*. Ideally, beyond that, yes, but only for public schema. – skaffman Apr 22 '11 at 17:33
  • 1
    I guess am still not understanding why URIs are used. From my understanding and according to Wikipedia and other resources, URI is defined as "a string of characters used to identify a name or a resource on the Internet". If local assemblies are being referenced and the namespace URI is not trying to identify an internet resource, why use URIs? Furthermore, HTTP stands for "hypertext transfer protocol". How does it make sense to prefix a namespace with any kind of transfer protocol? – oscilatingcretin Apr 22 '11 at 17:37
  • 6
    @oscilatingcretin: The namespace is an *arbitrary* identifier. You can put anything you want in there ("Grabblesnackers"), but using a URI is done by convention, presumably because it is guaranteed to be unique if you control the domain. – Robert Harvey Apr 22 '11 at 17:38
  • Also, when I used .NET namespaces in my example, I wasn't referring to .NET namespace format in and of itself, but using its simplicty and relative practicality as a basis. For example, to me, it would make more practical sense to use something like "Schemas.Microsoft.XmlDocumentTransform". While that does follow the .NET namespace format, it still makes sense on a more global scale, especially moreso than a URI-style string with a transfer protocol that's not even used. – oscilatingcretin Apr 22 '11 at 17:40
  • 3
    @oscilatingcretin: `Schemas.Microsoft.XmlDocumentTransform` is still a URI, and is just as valid as anything else. The wider convention, however, is to use URL-style URIs - it's *just a convention*. – skaffman Apr 22 '11 at 17:43
  • They tried to create a universal tool, and as all universal tools, the best way to get a good handle on what it does is with concrete and intuitive examples. To the design group, URLs seemed intuitive at the time. – GregC Apr 22 '11 at 17:47
  • 6
    Alright. Deleted last comment, so I apologize to anyone who's still responding to it. So it's basically all arbitrary. Someone with a big wig said, "We're going to prefix our URIs with http even though hypertext transfer protocol isn't even part of the equation. There's not necessarily any rhyme or reason to it, but I have the big wig here and so we're going to go ahead and prefix it with http. Why http and not ftp? Well, because I said so." So that's my take on things. Thanks for the discussion, guys. – oscilatingcretin Apr 22 '11 at 17:56
  • 4
    Here's a good article why XML namespaces are URIs, and why it was a mistake: http://www.xml.com/pub/a/2005/04/13/namespace-uris.html – Mas Aug 10 '11 at 08:45
  • 2
    @skaffman: it's not "just a convention" - it's how XML namespaces are defined. See http://www.w3.org/TR/xml-names/ - section 2.1 - "Definition: An XML namespace is identified by a URI reference [RFC3986]". As this document goes on to say, they can be URLs or URNs, which gives a lot of scope. – AAT Sep 24 '12 at 13:37
5

W3 explanation Here

Just like namespaces in .NET, namespaces in XML documents are designed to help prevent and resolve name collisions, especially if XML documents are from different organizations and/or domains of knowledge.

XML document format has been stylized by the same people responsible for HTML, so you may find syntactical similarities in elements of the format. Semantically, the dotNET and XML namespaces serve the same goal.

GregC
  • 7,517
  • 2
  • 48
  • 63
  • I understand the concepts of URIs and XML document formatting. My initial post addressed the question of why XML namespaces look like URLs. Yes, I know that a URL is a URI, but there is something distinctly recognizable about a URL. It has a protocol, a domain, a suffix, folder references, and, most of the time, a document. It has been made clear to me that the XML namespace format is what it is simply because original XML ganstas made a decision based on their understanding of how things would work at the time. If XML were invented today, its namespaces would most likely not look like a URL. – oscilatingcretin Apr 23 '11 at 01:07
  • 3
    Also, several people here have said that URL-style namespaces give uniqueness, but I don't see how. There is no uniqueness guarantee for any URI format, be it an XML- or .NET-style namespace (unless you're talking about a URL). Throwing "http" and ".com" into a namespace just doesn't have any logical backing in my opinion. What if someone failes to renew the domain name registration and someone else buys it (ahem Microsoft)? What good is their URL-style URI now? No consistency, imo. – oscilatingcretin Apr 23 '11 at 01:13
  • 1
    @oscilatingcretin: GUIDs aren't guaranteed to be unique either, but the likelihood of a properly generated GUID being identical to another is vanishingly small. Using URLs provides a reasonable assurance of uniqueness. – Robert Harvey May 05 '11 at 15:53
  • 2
    Reasonable in what way? No one has yet addressed my question of why a URL-style namespace makes sense. What does HTTP (hypertext transfer protocol) have to do with it? Why not FTP? Someone tell me why http:// schemas.microsoft.com/XML-Document-Transform makes sense over Microsoft.Schemas.XmlDocumentTransform. I know I have chosen an answer long ago, but I am all about further discussion on this topic – oscilatingcretin May 05 '11 at 23:27
  • 4
    I know this is old, but no one answered @oscilatingcretin. The assumption is that microsoft.com is owned by Microsoft and hence "controllable" in a sense. Not perfect by any means, but Microsoft and only Microsoft can publish a schema to microsoft.com/xyz. Unless they forget to renew the domain, etc... :) – Andrew Grothe Jul 16 '13 at 13:16
2

The core of the problem is that namespaces have to be URIs. There is no good reason for such a thing since all it needs to be is a unique identifier to give context for the defined elements.

Since they have to be URIs, all possibilities are senseless, because a scheme is needed (e.g. http) even though a namespace has nothing to do with such a thing.

So to answer the question of why: like all bad ideas, someone thought it was a good idea at the time.

dstibbe
  • 1,501
  • 13
  • 29