RE: [binaryXML-30] Binary XML problem statement.

>  
>  
> -----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