Musing over Namespaces

rev-bob at rev-bob at
Fri Dec 17 04:35:10 GMT 1999

>  > I think not.  The standards path is complete once the means to
>  > create and identify the namespace is possible.  What now needs to
>  > happen is for the technologists to create means by which company
>  > registries of namesspaces can be accessed and negotiated with such
>  > that for any contract, the ROA namespaces can be declared.
> I've noticed this assumption behind a lot of the Namespace-related
> postings (not just Len's) -- I guess it would be a good thing to have
> a global resolution mechanism of some kind, but I'm surprised that
> people consider Namespaces incomplete without this.  
> After all, there's nothing similar for (say) Java or Perl package
> names, and while having something like that would be convenient (and
> CPAN is very nice as far as it goes), the absence of a global
> resolution mechanism for figuring out what org.xml.sax or XML::Parser
> means doesn't seem to inhibit useful work in Java or Perl.
> Why is XML different?  Is it just that we come from the SGML
> background, where we consider structural validation to be part of a
> document rather than a process applied to it, or is there some kind of
> a fundamental difference between naming code and naming document
> nodes that no one has articulated yet?

Just to take a stab in the dark here, but wouldn't this fundamental difference be that Perl 
and Java are almost unilaterally self-contained parcels (hence, it doesn't matter what the 
package is named, because you're writing everything that deals with it anyway), but 
XML documents are designed for interchange - where the names don't just have to make 
sense to you, but also to an unknown client?

In other words, my only concern when naming a function or a class in a program is that I 
need to know what it is; I can name a variable "Fred" or a 50-char string class "Bubba" if 
I want to, and it doesn't matter - because nobody else needs to understand what those 
names mean.  However, if I'm writing a document that I'm going to send somewhere 
else for Joe to deal with, I'd better use names that Joe can understand and easily map.  
(For an HTML example, I like "BQ" much more than "BLOCKQUOTE" as an element 
name - but if I use BQ in my code, no UA will know what I'm talking about because BQ 
isn't defined anywhere.  If, OTOH, I slip a transformative preprocessor that morphs BQ 
into the defined BLOCKQUOTE somewhere between authoring and the public UA, that 
works fine.)

The difference you're looking for is one of scope.  Internal names don't matter to the 
outside world, because nobody outside has to do anything with them...but external 
names MUST be defined in some way, else nobody outside CAN do anything with 
them.  Am I expressing it clearly?

 Rev. Robert L. Hood  |
  Get Off The Cross!  |

Download NeoPlanet at

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as: and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo at the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list