Re: [xml-dev] When parsing speed matters (was Re: [xml-dev] No XMLBinari

["Stephen D. Williams" <sdw@lig.net>]

Elliotte Harold wrote:
> Michael Kay wrote:
>>>> *cough*While I love XML as everybody else on this mail list,  HUGE 
>>>> perfomances problems that ask for hardware can be a sign on the sky 
>>>> some people is using XML where a relational database can be
>>>> better*cough*
>>
>
> Or a native XML database.
>
>
Or an RDF database.  You do realize that SQL and XML databases will be 
subsumed by RDF databases and data models shortly, right?  Even for 
communicating extensible information between processes, we tend to see 
RDF (usually RDF/XML) as the first and best tool rather than XML.

Comparing XML to a relational database is mixing incompatible concepts 
to a large extent.  What is actually being referred to is XML vs. binary 
result set transport formats, i.e. something closer to a binary XML 
format.  Because of the historical mistake of defining ODBC as an API 
rather than a protocol, the protocols were somewhat optimized by each 
database company.  (I always blamed this on Microsoft until I found the 
ANSI ODBC standard some years back.  Of course, Microsoft may have been 
the driver or controlling the committee...  In any case, ODBC is one of 
the great blunders of IT over the last couple decades for a number of 
reasons.)

We need fast, compact encoding of both XML and RDF (and all similar 
formats such as JSON).  Ideally, a parse-free (i.e. no serialization or 
deserialization) mode would also be supported.

The W3C EXI working group is working on the base efficient XML format: 
we're writing the specification draft now.  I have more requirements and 
additional features to tackle the bigger problem.  The win is even 
larger for RDF than it is for XML, and the random access, indexing, 
delta, and directly modifiable properties and features that I insist on 
are even more appropriate.

sdw