Musing over Namespaces

[Ray Whitmer]

rev-bob at gotc.com wrote:

> 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?

This is not true.  We combine Java and Perl from a variety of sources and refer to these
classes from other packages from other sources -- significantly more diverse than our current
XML declarations in terms of one set of classes referring to another.

> 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.)

Packages are heavily reused and refer to the public declarations of other packages.

In Java, methods only to be used within a package are not given scope beyond that package and
can be renamed as desired.  But software packages would be quite useless without a significant
number of public declarations.

For example, take the W3C DOM Java bindings which exists almost purely of public
declarations.  It declares such common public names for use as "Document", "Comment", "Attr".
There are numerous conflicts between these compiled interface class names and classes in the
applications I use them in.  Without package name qualification of the classes, the situation
would be quite difficult not only distinguishing between ambiguous names, but also just trying
to keep track of which standard each class belonged to.

IMO, this is exactly what happens with XML, mixing different standard elements and
architectural forms from different specs in a single DTD or content model to produce a desired
result.

> 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?

No.  Java packages typically have lots of external names that matter to the outside.

Ray Whitmer
ray at xmission.com



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