- From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
- Date: Wed, 19 Feb 2003 13:56:40 -0700
- To: www-tag@w3.org
> > > -----Original Message----- > From: Noah Mendelsohn/Cambridge/IBM > [mailto:noah_mendelsohn@us.ibm.com] > Sent: Wednesday, February 19, 2003 2:20 PM > To: Mike Champion > Cc: www-tag@w3.org > > Actually, in the Web Services area, I've heard at least as > much interest attributed to (perceived) improvements in > serialization/parsing/deserialization time. Strongly agree. If the issue were just space, gzip-ing the XML is easily accomodated without any intervention by the W3C. But processing overhead must be considered, both in the zip/unzip and the serialize/parse steps. If an environment is bandwidth-constrained but processing-rich, gzip is a good solution, but with fast networks and limited hardware at each end, it can slow things down. True, sooner or later Moore's Law might rescue us even for web-enabled wristwatches and fridge magnets, but &deity; only knows what OTHER requirements those processors will be expected to meet by that time. (I'd note in that context that a 1 GHz Pentium processor could have easily met the processing requirements of a large university vintage 1975 or so, but is barely adequate for an engineering student today). The usage scenario I see [wearing my Software AG hat but NOT speaking authoritatively for my employer] for "binary XML" is much the same as Noah mentions for Web services: the overhead of parse-serialize-parse in XML pipelines between *standard* components (e.g. XML parsers, Xpath/Xquery engines, XSDL validators, DOM APIs, XSLT transforms, etc., all of which are defined on top of the Infoset rather than the XML syntax) repeatedly shows up as a bottleneck in actual profiling. A proprietary solution is possible, of course, since these pipelines are often an implementation detail of the product(s) rather than something exposed to the user. On the other hand, reinventing the wheel that dozens of other W3C member companies may be chipping away at seems inefficient at best and counterproductive to the XML industry at worst (if it keeps XML-based products from competing effectively with non-XML products in high-performance environments, or if it limits the reusability of standard components in actual products). Again, I don't really expect the TAG to do anything to solve these problems, but I hope that the Webarch document and Findings relevant to this topic reflect a careful consideration of the issues and tradeoffs we've mentioned. I'd like to see the experimentation and possible standardization take place *within* the context of the Webarch rather than being seen as antithetical to XML and Web architecture and best practice.
Received on Wednesday, 19 February 2003 15:57:36 UTC