1

I am really confused on how namespaces work.

Specifically, I read that the URI assigned to the prefix is not parsed.

If so, then what is the point of indicating a URI?

John Saunders
  • 160,644
  • 26
  • 247
  • 397
Eldan Shkolnikov
  • 441
  • 1
  • 6
  • 13

4 Answers4

2

The namespace URI is for all formal and practical purposes the name of the namespace; it needs to be distinct from the URI of unrelated namespaces, and the only meaningful operation is comparing it with another namespace URI.

There's a popular (but obviously not universal) tradition of choosing for a namespace URI a working HTTP URL for a XML Schema document defining elements in that namespace, but it is only an informal convention which doesn't affect the actual rules for either namespaces or schemas.

Lorenzo Gatti
  • 1,260
  • 1
  • 10
  • 15
0

If you look at the W3C's documents, you'll find some of the history of this. Basically, URIs were chosen for the same reason reverse-domain-names are often used for project names in Java: they aren't inherently meaningful, but they do provide some hint about who created them and what they might mean, and we already have practices in place to ensure against their being unintentionally reused (which could cause malfunctions.)

Back in the early days of Namespaces, we were using URLs as namespace names. It was generalized to URIs later (after the decision was made that the namespace name didn't necessarily point to anything), but many of the issues were specifically phrased in terms of URLs so my discussion's going to mainly reflect that subset of URI space.

There was at one point an intent that namespace names might be more meaningful. Tim Berners-Lee wanted them to point to someplace that provided additional information about the node types bound to that namespace -- not just a schema but an entry into his "Semantic Web" concept. That seems to have been dropped; I haven't heard much about the Semantic Web in years, at least not on more than a much-simplified and far-more-local level.

There was also an attempt to define behavior for relative URLs as namespace names. After much debate, TB-L conceded that this really didn't have workable semantics either, and the W3C declared that all namespace names should be formatted as absolute URLs or URIs and compared simply as strings. (More officially phrased: The use of relative URLs as namespace names is Deprecated until and unless someone comes up with a strong reason to use them. Individual tools may not check this, but documents using relative URLs as namespace names are Not Portable so you're very, very strongly advised to avoid them.)

If you are indecently lucky and/or whoever developed this document type is still trying to leverage the Semantic Web concept, there may be additional information about the namespace available at that URI. (That is, it may actually be functioning as a Uniform Resource Locator rather than just as a Uniform Resource Identifier.) But as far as the standards go right now, there's no promise that this point in URI-space is occupied, or what can be found there if so. Basically, dereferencing a namespace name is an undefined operation.

It really is simpler, and more correct for now, to just treat the Namespace Name as a string that must be formatted as an absolute URL or URI for uniqueness' sake.

(I used to have a pointer to an excellent document which explained this more clearly and more officially, but it's been years since anyone has asked me this particular question and I've misplaced it. If I find it, I'll update this answer.)

keshlam
  • 7,931
  • 2
  • 19
  • 33
  • Beg pardon? I did say URI throughout my note. I'm not sure what you're objecting to. (I was involved in some of these discussions. It's an ... interesting ... experience to win an argument against a guy whose name is almost synonymous with the Web.) – keshlam Dec 28 '13 at 05:29
  • Can you give an example of a relative URI which is not a URL? – John Saunders Dec 28 '13 at 07:48
  • As mentioned in http://en.wikipedia.org/wiki/Uniform_resource_identifier, among others, "Technical publications, especially standards produced by the IETF and by the W3C, normally reflect a view outlined in a W3C Recommendation of 2001, which acknowledges the precedence of the term URI rather than endorsing any formal subdivision into URL and URN. I was on a W3C working group; I use the terms W3C-style. "Relative" applies to URLs, but URLs are a subset of URIs, and are the main form which was being referenced when the Namespaces In XML Recommendation was being designed, debated, and approved. – keshlam Dec 28 '13 at 18:47
  • 1
    Ok, I acknowledge your perspective, but since most readers will have an "outsider" perspective, perhaps you should switch to that perspective when discussing the issue among outsiders? [so] won't allow me to remove the downvote unless you edit your answer. Perhaps you could add some of this "perspective" information? – John Saunders Dec 28 '13 at 21:01
  • Thanks for the great answer! Is it necessary to provide an absolute link to namespaces?? – Eldan Shkolnikov Dec 28 '13 at 21:56
  • If you're using "absolute link" to mean "absolute URI", the answer is yes. "The use of relative URI references, including same-document references, in namespace declarations is deprecated." http://www.w3.org/TR/REC-xml-names/#iri-use – keshlam Dec 28 '13 at 22:35
-1

The namespace prefix defines how the XML tag name is to be intrepreted. Presumably, the author of a namespace has defined a schema for interpretation. The namespace also avoids name conflicts when an XML document is constructed from more than one source, where each source uses the same tag name but for different meanings.

Below is a link to the W3C school tutorial on XML namespaces: http://www.w3schools.com/xml/xml_namespaces.asp

Andrew - OpenGeoCode
  • 2,299
  • 18
  • 15
  • Andrew thanks for the response. Can you please explain me what do you mean by "The author of a namespace has defined a schema for interpretation" Specifically what do you mean by "defining a schema for interpretation"? – Eldan Shkolnikov Dec 28 '13 at 00:06
  • Oracle has a pretty good explanation of namespaces and XML schemas at: http://www.oracle.com/technetwork/articles/srivastava-namespaces-092580.html – Andrew - OpenGeoCode Dec 28 '13 at 00:49
  • -1 for linking to a w3schools tutorial. As usual, it is wrong. – John Saunders Dec 28 '13 at 01:56
-2

The point is to have something readable, saying and unique. Creator can set URI to some folder on his company site.

CONSIDER ALTERNATIVES

  1. just names

    Actually they already are just names. It is only recommendation to use URIs. Names have a problem of collisions (non-unique). Also, names can be not saying if somebody wish to name his file format as superpooper.

  2. dot-notated hierarchical names, like packages in Java and C#.

    It's actually the same as URIs, but can probably contain collisions when many bodies wish to have the same name like com.super.pooper.format.

  3. GUID

    GUIDs are absolutely unique, but not readeable and not saying. What this can mean {000209FE-0000-0000-C000-000000000046}?

So, creators of XML invented to reuse the results of already done work. Most bodies already have their web-sites. Which means that they already have chosen readable names and folder structure which is unique enough.

This is brilliant idea I think.

But you can ignore this idea and name your namespace as AAA.

Community
  • 1
  • 1
Suzan Cioc
  • 29,281
  • 63
  • 213
  • 385
  • Hey Susan, Thanks for the response. What exactly do you mean "to have something readable" Do you mean as a reference as to what the prefix is used for? – Eldan Shkolnikov Dec 27 '13 at 23:49
  • `readeable` means `perceptable by eye`. – Suzan Cioc Dec 28 '13 at 00:34
  • I presume "readable" here was intended to mean "easily recognizable by, and if well-chosen possibly meaningful to, a human." – keshlam Dec 28 '13 at 00:46
  • -1: Your answer is written as though you believe that namespaces are always URLs (you talk about work already done, and web sites). That is not the case. – John Saunders Dec 28 '13 at 01:54