Cart
[Home] [By Thread] [By Date] [Recent Entries]
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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
