xml-dev - re: Re: Musing over Namespaces

[rev-bob@gotc.com]

> > 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@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@ic.ac.uk the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)