Musing over Namespaces

[David Megginson]

rev-bob at gotc.com writes:

> > I'd considered that possibility, but it's not true.  Consider the
> > following, very typical case in the Java world:
> > 
> > 1. I write a compiled Java app that references org.xml.sax.Parser.
> > 2. I send you the app.
> > 3. You run the app, and the JVM complains that org.xml.sax.Parser is
> >    not found.
> 
> Not to offend, but I consider that hideously sloppy.  If you're
> going to use a module, you have to make sure the client has that
> module.  Otherwise, to be blunt, you're not doing your job as a
> programmer.

That is exactly my point.

> You wouldn't define a variable as being of type Jimmy without
> defining what "Jimmy" means (either by explicit code or through
> reference); why would you try to use method Frank on a document
> without defining where method "Frank" can be found?

But Java and Perl have global as well as local names, and they both
have a high degree of code reuse.  There is (to my knowledge) only one
org.xml.sax Java package in the world -- people who reference
org.xml.sax are not definining it the way that you define your local
"jimmy" variable, and in an ideal world, there should be no reason to
bundle sax.jar with every app that happens to use it.

> If you're going to use oxsP in your application, you need to bundle
> it.  Say, here we go with namespaces in XML again - "if you're going
> to use <foo/>, you need to indicate what <foo/> means".

I'd rephrase slightly:

- If you're going to use oxsP in your application, you need to bundle
  it or tell the users where they can find it.

- If you're going to use {http://www.foo.com/ns}foo in your XML
  document, you need to indicate what {http://www.foo.com/ns}foo
  means, tell the users where they can find out, or at least provide
  default rules for dealing with unrecognized elements and attributes.

Neither of these is The Way It Should Be, but it's interesting that
the problem of global resolution, which some people claim is trivially
easy and should have been solved ages ago for XML Namespaces, has not
yet been solved even for the older, enormous, and lucrative Java and
Perl markets.

[snip]

> In case there is any doubt, let me spell my position out in no
> uncertain terms: Namespaces are utterly pointless - even
> counterproductive! - if there is no standard way to resolve them.
> This goes beyond "helpful" into the core realm of "essential".

An interesting, if contradictory argument.  Why are Java package names
(which are global like XML Namespaces) not also pointless and
counterproductive, then, since there's no standard way to resolve
them?  Above, you argue that it's OK (in fact, essential) to have to
bundle shared Java class libraries with every app that uses them, but
then you state that it's not OK to have to bundle documentation for
shared global XML element or attribute types with every document type
that uses them.

It may be that both statements are true, but I still see no crisp
distinction.


All the best,


David

-- 
David Megginson                 david at megginson.com
           http://www.megginson.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)