OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xml-bin] :-(




> -----Original Message-----
> From: sdw@lig.net [mailto:sdw@lig.net]
> Sent: 19 April 2001 21:52
> To: xml-bin@warhead.org.uk; xml-dev@lists.xml.org
> Subject: Re: [Xml-bin] :-(
> 
> 
> "Al B. Snell" wrote:
> > 
> > http://www.xml.com/pub/a/2001/04/18/binaryXML.html
> > 
> > Didn't really capture our side of the argument, it seems...
> 
> Filtering out all opposing arguments as not worth printing seems a bit
> unfair.  There's a lot of "kill the solution before it matures" going on
> here.  

I certainly wasn't attempting to 'kill the solution'.

Having read through every posting in those threads, there seemed to 
be several voices in favour of the proposal, and a many more who, 
if not outright against the proposal, were requesting some concrete 
evidence that the effort was worth it at all.

As I wrote, the issue has surfaced several times since I've 
been an XML-DEV member (most recently in January), and in most 
cases its the low-level issues ('space and efficiency') that are often 
discussed.

However these are not the entire picture, something that Bohlman 
and Perry communicated very clearly I think. And thats why I chose 
to highlight these points - simply because these issues hadn't been 
articulated in previous debates.

> On the other hand, I have no problem with people asking for
> evidence that it's a better method.  It's just a hypothesis waiting to
> be properly tested.  And no, my solution hasn't been tested yet.

You're right, its always worth testing hypotheses. 

Yet, the evidence that I believe several list members were seeking 
was more a review of the current real (and not perceived) 
bottle-necks in processing textual XML (documents or otherwise). 
And, as RickJ noted, these bottle-necks may be alleviated by 
using techniques *other* than binary encoding.

The general problem (at least to me) is much more interesting: identify 
areas that could be improved, and then seek mechanisms for solving 
them. Binary encoding is just *one* possible solution, and (like all 
optimisations) will involve a trade-off of other features. Casting a 
wider net (short-tagging, binary indexes, lazy DOMs) might actually 
produce something beneficial in a greater number of cases.

(As a side note, what might seem like apparent disinterest may be 
more a sign that concerns are centred on other areas of the 
XML framework, rather than this most fundamental one. 
Although there are certainly a few loose bricks among the 
foundations...)

Cheers,

L.

-- 
Leigh Dodds, Systems Architect       | "Pluralitas non est ponenda
http://weblogs.userland.com/eclectic |    sine necessitate"
http://www.xml.com/pub/xmldeviant    |     -- William of Ockham