xml-dev - Re: SAX2: Namespace Processing and NSUtils helper class

[Tim Bray <tbray@textuality.com>]

At 02:06 PM 12/15/99 -0500, Simon St.Laurent wrote:
>>We talked about this a few months ago, but I'd be happy to hear what
>>people think now.
>
>I'm afraid I think this is a hideous idea, and that's an understatement.
>Even apart from code bloat - having to deal with two parts of a name means
>twice as much code every place the name matters - I'm really not sure I
>like the logic behind this approach.  

Hmm, I perceive the opposite.  I anticipate that patterns such as the 
following will be very common - not sax primitives, but you'll see the idea.

 while (iterator.hasNext())
 {
    whatever = (Whatever) iterator.next();
    if (whatever.ns().equals(myNamespace))
    doMyProcessing(whatever.name());
 }

i.e. the namespace processing is highly decoupled from the name
processing.  Another way to say it is that much name processing will
be written to deal with one particular vocabulary, and want to just
deal with names, assuming the NS to have been checked already.

Given this, then if the parser insisted on giving you these things 
glued together, you'd actually have to do extra work to pick them
apart before doing your real work.  Since the low level parsing
code is going to have them in two places anyhow, it seems real awkward
to parse them apart, glue them together with curly braces, and then
pick them apart again to do the real work.  The namespace spec de jure
and de facto contemplates qualified names as being 2-part things, and
modern programming techniques can deal with multi-part data objects,
so why why all this concatenation side-stepping?

The whole {ns}name notion has a smell to me of pretending that we're
still living in the pre-namespace era, and we're not.  I mean, you 
could take all the structs in your C programs and concatenate the
string representatioons of all the members together and pick them apart
to do work with them, but that would be perverse.  So is {ns}name.

>There are two cases where I think this approach could be useful. The first
>is separating components from different namespaces for different
>processing, which could be a good idea but isn't worth the cost so far as
>I'm concerned. 

Hmm... I have the notion that this is probably the most common use case.
Of course, we're both prognosticating, i.e. guessing.

>The second case is downright funny to me at least,
>situations where you want to discard the namespace entirely and focus only
>on the local part.

I think this is going to happen all the time, once you've decided that
this is the namespace you know about; then you just focus on elements &
attributes in the old-fashioned way.  -Tim



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)