Re: TAG opinion on XML Binary Format

Isn't this precisely the kind of thing Incubator Groups were desgined for?

Jonathan

Stephen D. Williams wrote:

> Your collective analysis agrees with our thinking to a large extent.  
> What is unclear is the implication for next steps.  You note that 
> "more detailed analysis is needed", "further careful analysis is 
> needed before the W3C commits to a direction", "we suggest that a 
> quantitative analysis is necessary", "representative binary 
> technologies be benchmarked and analyzed", and "the TAG would like to 
> see the above issues addressed".  It is unclear how you expect to 
> proceed or how you expect "us" to proceed to accomplish this in a 
> coherent, timely, and effective way.  "We" expected that these were 
> activities to be performed in the early stages of a new working 
> group.  Our documents were prepared, secondarily, for those purposes.  
> If you (collectively) have something else in mind, please enlighten us 
> to both to your pending options and recommendations and our options.
>
> Our documents should have made it clear that our conclusion is that 
> one format could support all use cases well, although in some sense 
> different modes will need to be supported (for example, a range of 
> self-contained on one extreme and limited structure, externally typed, 
> range restricted binary scalars on the other).  To make the coherency 
> of this clear, it is probable that both extremes might be needed in a 
> single instance.  I would be happy to elaborate.  We expected to start 
> with consideration of multiple strategies, but produce a result that 
> would be the best of all available ideas.
>
> I was particularly thrilled by this paragraph:
> "Benchmark environments should be as representative as possible of 
> fully optimized implementations, not just of the XML parser, but of 
> the surrounding application or middleware stack.  We note that 
> different application-level optimizations may be necessary to maximize 
> the performance of the Binary or text cases respectively.  Care should 
> especially be taken to ensure that the performance of particular APIs 
> such as DOM or SAX does not obscure the performance possible with 
> either option (e.g. both SAX and DOM can easily result in high 
> overhead string conversions when UTF-8 is used.)"
>
> This is exactly where my thinking is.
>

Received on Saturday, 28 May 2005 16:05:17 UTC