SAX2: Namespace Processing and NSUtils helper class

[Didier PH Martin]

Hi Tim,

Tim said:
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());
 }

Didier reply:
I noticed, in our work within the OpenJade group (which also involve parser
development) that new needs are emerging. And for the gentleman who asked if
there is some Open Source developement in the markup techs, yes, there are
and OpenJade is one of them (but probably the only group dedicated to markup
techs ;-)

So, we noticed these new needs. In fact, these needs are created by the
different ways and maybe new ways to look at and process an XML document. So
let's speak of parsing pattern.

a) A pattern we discovered (or re-discovered) is the multi-event handler
pattern. For a single document, we may have multiple event handler. For
instance, the same document may be perceived as a topic map document, an
xlink document and a rdf document. These three domains have their respective
domain handler. So, the first pattern to resolve is how can we dispatch the
right event to the right event handler. This is a problem contrary to other
event based systems like for instance VB where we have multiple event
sources and a single event handler sink. So instead, we have the pattern of
having a single event source but multiple event sinks. No actual parsers can
do that. hummm, Can they? Maybe with (b) as an answer.

b) an other pattern, this one more well known, is a several pass parsing
pattern. Where each domain is processed by a separate document handler (i.e.
event handler). So, if we keep the same example, the document is first
parsed and handled for the topic map domain, then for the xlink domain and
then finally for the rdf domain. Obviously, this pattern won't win the speed
contest.

c)An other pattern is to build an internal model (i.e. a grove) and have
this grove being accessed by an API (i.e. a DOM). In this case, we have a
single pass for parsing. The processing or interpretation phase could be
either (a) a single pass interpretation or (b) a multiple pass
interpretation. As you know, this last pattern is not event driven.

As you noticed, I didn't use the term pattern in the sense of Alexander (not
the Alexander the great but the architect :-)

>From an observation of both RDF and XLink, dispatching to the right handler
requires that the event source fires the event and the event sink to receive
the current element and attribute if:
a) this element is tagged with a name space identifier and that an event
handler is associated to this name space.
b) an attribute is tagged with a name space identifier and that an event
handler is associated to this name space.

Off course, each handler (or in this case name space handler) has to keep a
certain memory of the processing or interpretation context.

We are now studying seriously the pattern (a) because it allows _real_ reuse
and combination of domain handlers and thus (here is the plug for your
managers dear Dilbert(s) of this world) it reduces development cost (and has
been prescribed to reduces headaches by the federal health department :-))

Cheers
Didier PH Martin
----------------------------------------------
Email: martind at netfolder.com
Conferences Web New York (http://www.mfweb.com)
Book to come soon: XML Pro published by Wrox Press
Products: http://www.netfolder.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)