[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] sax-ext handlers (was: SAX2 Lexical Handler Suggestions)
If people need some odd events, which are 1% of cases, may be it is possible to think about that as SAX properties and extensions? We already have extension package sax-ext in SAX for Lexical and Declaration Handlers. Any new stuff can go there and it will be up to implementors of SAX parsers, which extensions to support based on their customer base needs. Of course, such extensions must be strictly optional for the whole idea to be acceptable. And this optional handlers should be also discussed, agreed upon and somehow published, like it is done for Lexical and DeclHanders. Then really useful extensions will become de facto standard just because of a lot of people, using them. For example, I thought that interface like: interface ISAXAttributes { void attributeName(String QName, String LocalName, String RawName); void attributeValue(String Value); } makes a lot of sense. Of course, it's not very good to implement in a parser (SAX events producer) because of a namespace problem (you don't know namespace until you finish parsing start tag). But for SAX events consumers it makes a lot of sense. It allows users to generate attributes easily without creating a SAXAtrributes object for every tag. Just my 2 pennies to the discussion. Eldar -----Original Message----- From: David Brownell [mailto:david-b@p...] Sent: Wednesday, July 12, 2000 11:57 AM Subject: Re: SAX2 Lexical Handler Suggestions ... and it's quite well known that editors require quite a lot more than "Simple" functionality. In fact they usually demand all kinds of extra information which the XML infoset explicitly discarded using the 80/20% rule. (IMHO more lie 99/1 in this case.) After seeing bits and pieces of editor requirements for several years now, I think that if SAX is to support that functionality it should be through specific APIs (EditorHandler, maybe) addressing editor issues. If your itch involves having such features, I suggest you scratch it in that way. (I don't like how DOM cluttered up the 80% simple case with incomplate support for someone's 20%, which btw is often labeled as "editor" stuff, and want to see SAX stay uncluttered.) It would need to expose at least part of a token level event stream ... so that editors would not play with the whitespace separating attributes (or outside of the root element), rearrange attributes, change text encodings for documents, and so on. - Dave
|
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
|