Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: SAX for Binary Encodings (SAD-SAX)
 Bill de hÓra wrote: >> What is it about this proposal that generates the heat? >> Obviously, I'm missing something here. Please try to explain the issue >> as clearly as you can. > > > SAX2 is designed to process XML. XML is encoded with Unicode. Your > proposal is trying to work around that. > You say SAX2 is designed to process XML, but what in the API really forces that? SAX2 is designed to process something that has leaf nodes of text (be they character data or comments or PIs) wrapped in nestable containers which have a textual name and a mapping of textual 'attribute' names to textual values, right? XML is one such thing, but there are *already* others. SAX will work just fine with those, too. You can have an entire SAX pipeline without a single byte of XML; a database backend that emits SAX events 'faking' an XML document that goes into an XSLT engine that outputs a string of HTML. No XML actually involved! There's a conceptual 'virtual' XML document that exists between the database and the XSLT engine, but no pointy brackets were harmed in its construction :-) I presume this is quite common; I've personally been involved in a project that did something similar, just with DOM trees instead of SAX as the glue. All the guy is proposing to expand upon is the idea that element and attribute content be optionally presented by the SAX API as native values, where the SAX parser has enough information to do so. He didn't explicitly state that there would be mechanisms to handle the case where type information is still available, perhaps because he incorrectly assumed that the readership of his email would stop and think "Oh wait, SAX *already* works where there's no type information available! So it can just fall back to that behaviour or something! Not a problem!", so didn't sit and explain the obvious at them? :-) >> And, as Amelia demands, it >> is not defined "in terms of WXS" or any other type system. This is >> good since SAX shouldn't be encumbered with the debate over these type >> systems. Let those battles happen elsewhere. > > I think the issue is that some are wondering why SAX ought to be > encumbered with non-Unicode forms for Infosets. It doesn't have to be non-Unicode, now, does it? It would be quite useful for normal XML with an associated schema, too. The original poster was coming at this issue from the viewpoint of binary encodings where it's more efficient to present the code directly with a native integer than to convert from two's complement form to text only to have the application convert back again - but the application of a typed-values-in-SAX interface is wide than that! > > Bill de hÓra > ABS 
|
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
|
|||||||||
