[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SAX2: Namespace Processing and NSUtils helper class

  • From: Tim Bray <tbray@t...>
  • To: "Simon St.Laurent" <simonstl@s...>, XMLDev list <xml-dev@i...>
  • Date: Wed, 15 Dec 1999 11:57:11 -0800

Re: SAX2: Namespace Processing and NSUtils helper class
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@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To unsubscribe, mailto:majordomo@i... the following message;
unsubscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.