[
Lists Home |
Date Index |
Thread Index
]
On Thursday 06 February 2003 07:25, Tahir Hashmi wrote:
> * Random Access: This is not supported by XML, so it can't be
> supported by xqML.
It's not supported by UnicodeWithAngleBrackets but there's nothing stopping
you doing it at the Infoset level - look at XPath.
There are conceivable and existing formats for XML infosets that would allow
one to evaluate XPath expressions without it needing to read the whole
thing...
> However, indexes on complete documents can be
> created by the serving applications and xqML can provide for indexes
> to be included in the beginning of the document (eww! this is
> getting messy)
:-)
> * Competition with compression: xqML in it's current format is as
> structured as XML so it too compresses well. In an experiment[1] a
> 12 kB HTML document zipped to 2 kB. The (handwritten) BE for the
> same document took 3 kB and when zipped, it took less than 1000
> bytes.
Mmmm, it bugs me when people compare gzipped XML with $binary_format. They
should compare XML with $binary_format and gzipped XML with gzipepd
$binary_format. gzipped $binary_format will, in general, be the smallest of
them all, and yet faster to read/write than gzipped XML.
> I haven't carried out proper tests yet for two reasons - the API is
> still too elementary to allow writing large test cases without much
> effort :p The second reason is that since data is not touched in xqML,
> how much compaction is achieved depends a lot on the percentage of
> markup, thus invalidating any claims for a real-world
> expectation. Even for 100% markup, compaction depends on the length of
> identifiers in the specs. I may specify
> extremely_large_element_names_like_this in the spec and jump around
> with claims of 99% size-reduction.
Welcome to the wonderful world of marketing :-)
ABS
--
A city is like a large, complex, rabbit
- ARP
|
