Musing over Namespaces
rev-bob at gotc.com
rev-bob at gotc.com
Sat Dec 18 02:51:15 GMT 1999
> > 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?
>
> 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. 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?
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 find it very hard to see any difference between that case and the
> following one:
>
> 1. I compile a data record in XML format that includes an element
> named {http://www.foo.com/ns/}alpha.
> 2. I send you the data record.
> 3. You process the record, and your processing code complains that
> {http://www.foo.com/ns/}alpha is not recognized.
Agreed; the cases seem precisely analagous - and IMO, both are utterly inexcusable.
> In neither case is there any automatic resolution mechanism to help
> you -- the JVM won't go out on the Web and find org.xml.sax.Parser for
> you if it's not already on your classpath. I'm not disputing that
> something like this could be helpful (both for Java and Namespaces),
> but I am disputing that Namespaces (or Java packages) are
> fundamentally incomplete without it.
Here's where I don't get you. Here we have a big, gaping hole in usability - and you're
saying that the hole doesn't need to be plugged?!? I un-comprehend that point of view to
such a staggering degree that I can't even frame the objection; it's like going outside in
the middle of a thunderstorm and being surprised because water's falling from the sky.
The words "blindingly obvious" come to mind - you provide what is needed to run your
program (or parse your document), because you cannot count on someone else to
magically know what (classes|elements) you used and take the initiative to download the
definitions manually. Providing the required modules is YOUR job as author, not the
USER'S job!
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".
> > 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.
>
> But they do need to know -- see my example above. The difference is
> that once you have the class files for org.xml.sax.Parser, you're
> fine, while it's far from obvious what you *could* retrieve that would
> help with {http://www.foo.com/ns/}alpha.
Uh-uh. You misunderstand (and being the second person to do so, I blame myself) - I'm
saying that if I write, say, the method foo.bar(x), I can name the variables inside the
bar() handler however I please. I can call the lone parameter Bubba, manipulate it using
variables Joe, Lily, Susan, and Ethel, and return the value of the resulting Martha - and it
doesn't matter. I have a JavaScript example handy; observe:
function parse(z) {
x = 0; isthere = false;
while ((x <= ua_max) && (!isthere))
{ isthere = (z.indexOf(ua_Arr[x],0) >= 0); x++; }
return(!isthere);
}
I could just as easily rewrite this as the following:
function parse(Martha) {
Wilma = 0; Cathy = false;
while ((Wilma <= ua_max) && (!Cathy))
{ Cathy = (Martha.indexOf(ua_Arr[Wilma],0) >= 0); Wilma++; }
return(!Cathy);
}
That function will work exactly like the first one - no difference at all. Why? Because
Martha, Wilma, and Cathy are all purely INTERNAL. Nothing outside this function
sees them. At all. Period. Conversely, the parse(), ua_max, and ua_Arr names are
external, and so they can't be changed. Your oxsP class reference is analagous to
discussing parse(), but I'm talking about Martha.
> > 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.
>
> That Joe can understand, or that his software can understand? There's
> a significant difference there.
Who says "Joe" identifies a person? Come on; I used human names for software
references all through that message - why do you assume that this use of Joe is any
different from my prior uses of Bubba and Frank? Think outside the box for a minute.
> We could set up some mechanism so that Joe's software could automatically retrieve a
> schema or schema fragment that covers {http://www.foo.com/ns/}alpha, but that's not
> much help -- Joe's software could tell that it's valid or invalid (whoopee!), but it still
> couldn't tell what it means.
Exactly what do you mean by "couldn't tell what it means"? Do you mean that the
retrieved information is semantic and hence has no bearing on "How do I handle
foo:alpha?", or do you mean that the retrieved information is relevant to the processing,
but simply insufficient to handle the task?
Either way, the goal is not being addressed. The whole idea behind XML is that you can
write your own tags. A natural followup to this is that you'll want to share tags with
other people. From there, it's a short step to the realization that sharing by reference is
better than sharing by cut-and-paste. And yet, at this point, there seems to be a lot of
hand-wringing over how to handle sharing by reference, or even if there's a need to
handle it at all.
Am I the only one who sees "Duh!" written all over this issue? We're going to have
numerous XML tagsets out there - fact. (Hello - "eXtensible" ring any bells?) The
people developing documents are going to want to share tags - fact. Therefore, there
needs to be a way to identify where a tag comes from and where an engine needs to look
for instructions on how to handle it - "Duh!" That requires a standard form of resource
location and retrieval (URI, XPointer, whatever). Some uses of this technology will
require a local definition to take the helm - thus, we need a way to handle that.
Is this really such a contentious and complicated issue? The only reason to have XML is
to facilitate data exchange - and if some form of transformation wasn't involved, people
could simply send each other MS Office files all day long. "Should we handle this?" isn't
the question. The question is "How do we handle this?" - because we've got to do it.
There's simply no alternative...other than shutting XML down and going home, of
course.
Rev. Robert L. Hood | http://rev-bob.gotc.com/
Get Off The Cross! | http://www.gotc.com/
Download NeoPlanet at http://www.neoplanet.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)
More information about the Xml-dev
mailing list