XObjects

[Tyler Baker]

Michael Kay wrote:

> Tyler Baker wrote:
> >I think you are all missing the point here about what I was talking about.
> In
> >simple terms this is how it all works and it all has nothing to do with the
> DOM.
> >
> >(1) There is a root element handler that is passed to the parser which
> handles
> >all of the events generated by parsing the root element
> >
> >(2) All of the generic events of SAX you could consider are delegated down
> to
> >the currently selected parent element which is receiving character,
> element, and
> >pi events among others
> >
> >(3) No registry, bindings, or any other muckety muck is necessary
>
> This is the way an early version of SAXON worked. I found with experience
> that it was simpler to define the association between an element-type and an
> element-handler class using a setElementHandler(tag, class) interface,
> rather than defining it in the element handler for the parent class. For
> example, it works far better when the processing for a <A> tag is identical
> regardless whether it appears within an <X>, a <Y> or a <Z>. (If different
> behaviour is required, SAXON also allows different element handlers to be
> used for <A> depending on whether it appears within an <X>, a <Y> or a <Z>.)

I feel you are somewhat correct for entire applications, but for components
having them need to have some outside knowledge of a global registry causes
obvious problems.  I have already tried the registry approach and found huge
pains with it.  I guess it all depends on the type of application you have.  For
the app I have, it is very component-oriented, hence my bias here.

> A compromise suggested by XSL, and which has been requested by users as a
> SAXON enhancement, is for the parent element to say whether or not the
> children are to be processed, while retaining document-level rules that
> define how they should be processed.

XSL is a totally different ballgame, though I see what you are trying to day
here.  Unfortunately, this sort of compromise looks as if it will complicate
things even further for XML processing.  My experience tells me not to spread
around functional processing into lots of different areas, but try and keep it
clean and concise in one block.  This sort of compromise spreads the element
handler lookup and the vetoing of particular element handlers into two different
areas.

Tyler


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/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe 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)