[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XObjects
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@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...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|