SAX2: Namespace Processing and NSUtils helper class

[Thomas B. Passin]

Tim Bray wrote:
> 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.
>

Both cases will and do happen.  Like in XSLT, you don't have to call the
namespace "xsl", but whatever you do call it, your xslt tag names have to
have the same "local" names (like "apply-templates").  This fits the second
case, above.

On the other hand, there are plenty of explanations of using namespaces out
there where two different namespaces use the same local names - the authors
presumably like to come up with extreme examples.

So we need to be able to work either way, which Tim's way would do.  As for
code bloat, if you use the same method calls to handle the two name parts,
there would only be one actual copy of the code in memory, wouldn't there?
(I suppose that's somewhat language dependent - Java people will set me
straight).

> 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
>
>
Tom Passin


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)