XObjects

[Michael Kay]

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>.)

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.

Mike Kay


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)