[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: XML Binary Characterization WG public list availabl e
No disagreement with that assessment. Robin's announcement asked that flamefests be held here and not on that list, but the list asked for discussions that will inevitably lead to flamefests. I'd not seen the term 'optimized XML' before and wondered how that related to 'binary', a term I am familiar with. This is clearly an alternative format to XML as we know it. I won't argue the merits for that here today. The case is made in some domains for 'alternatives' but as we've repeated here several times, no one knows if that really is a plurality. len From: Michael Champion [mailto:mc@x...] On Apr 9, 2004, at 9:18 AM, Bullard, Claude L (Len) wrote: > This will open Pandora's Box. > > Some applications do need a binary, such as X3D, > and are moving smartly to design one. Terms such > as 'optimized XML' scare me. Pandora's box was opened in 1997. XML 1.0 is optimized for SGML compatibility, and that turns out to be a decent compromise between human readability and machine processability for a lot of common use cases. All sorts of other use cases might be optimized: Wiki-like markup languages are optimized for human editability; there are XML serializations that are optimized to save space, (see http://xml.coverpages.org/xmlAndCompression.html) and there are XML serializations that are optimized to be quickly parseable (e.g. http://www.ximpleware.com/). XML has reached a point in it's evolution where people with some of these use cases are wondering whether XML's non-optimality for one thing or another outweighs the very real benefits, and are trying to figure out how to refactor things to get most of XML's benefits with fewer of its costs. My experience is very different from Elliotte Rusty Harold's -- I am *frequently* asked to help sort out the tradeoff between XML's standardization, loose coupling, etc. and the very real overheads it imposes... Indeed at this very moment I should be writing up a rationale for why XML makes sense for a particular prospect's application even though performance will suffer (or more hardware required). Others, e.g. with wireless applications, choke on the reality that XML is a "fat" format, GPRS has serious latency issues that are exacerbated when XML is in the picture, and exploiting a wireless device's processor for conventional compression algorithms just drains the battery all the faster. The question is whether there is one, or a manageable number greater than one, alternative format(s) that can cover a signficant range of use cases and still parse into the XML Infoset. "Optimized" is the right word, IMHO, because it forces one to ask "optimized for what?", and that forces one to measure time and space overheads in real use cases with real code. That's my understanding of what the "binary characterization WG" is doing, and I think it's a great idea to do this collectively and publicly so that further work can proceed from a common knowledge base.
|
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
|