Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX2: Interning names in namespaces
 At 1:59 AM 2/8/00, Stefan Haustein wrote: >Terje Norderhaug wrote: >> >> A "programmer" understands the implications of the namespace recommendation >> and are savvy in object oriented programming. Programmers are free to use >> >> if (name == myPrice) .... >> else if (name == myQtyty) .... >> >> Unless names are interned in namespaces, >> specialists would be limited to the less efficient techniques of beginners >> and scripters when using SAX. > >Assume we have m namespaces and n elements each, and the SAX java >intering feature is activated. Your "programmers" code needs up to n*m >comparisons to find the right element. The "scripters" code >needs up to n+m comparisons only, so I would not call your "programmers" >code more efficient. The "programmers" can choose whatever implementation is most favorable. Thus, even in a worst-case scenario like you describe the "programmers" code will always be at least as efficient as that of the "scripters". However, using a n*m sized if/else construct would be a rather clumpsy implementation. A switch/case would be more readable and allows the compiler to optimize for speed by reducing the number of comparisons. Besides, a smart compiler may recognize the constants in the if/else and anyway compile it as if it was a switch instead of as a sequence of n*m comparisons. Ensuring a unique instance of each element type particularly benefits processing and filtering of markup. It allows advanced processors to use techniques that wouldn't be feasible or efficient enough otherwise. Let me illustrate some advanced markup filtering techniques by using a real world example. I have a filter called the Stylizer [1] that emulates a CSS style sheet for the benefit of legacy browsers. The Stylizer adds presentational tags to HTML at serving time based on a style sheet. It works by receiving startElement and endElement events, checking the style sheet for matching selectors, then add attributes or call startElement methods to insert presentational markup in the event stream. The Stylizer uses different processing depending on the element type. I implemented this by specializing the startElement method on the unique interned instance of the element name. For example, the Stylizer has a startElement method that is specialized on the BODY element type so that it only is activated when the element type matches BODY. When dispatched, the startElement method for BODY looks up the appropriate selector in the internal representation of the style sheet (e.g. "BODY"), adds new attributes for style properties like color, and eventually calls startElement one or more times for adding presentational tags like CENTER. A related technique is to use a hashtable to dispatch various processing rules depending on the element type. The hash table is populated with processing rules, possibly loaded at compile/runtime from a style sheet or other external definition. At runtime, the startElement method looks up the element type in the hashtable and processes the event based on the rule. Given namespace interned element types, the hashtable lookup can be very efficient as the hashing is on identity. Without namespace interned element types, one might be required to maintain a separate hash table for each namespace, and lookups will be much slower as the tables have to be keyed on equality. [1] http://interaction.in-progress.com/components/stylizer -- Terje Norderhaug <terje@i...> President & Chief Technologist Media Design in*Progress San Diego, California Software for Mac Web Professionals at <http://www.in-progress.com>. Take advantage of XML with Emile, the first XML editor for Mac. 
|
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
|
|||||||||
