[
Lists Home |
Date Index |
Thread Index
]
Not sure what you mean, Scott. The changes to the actual XBIS encoding
format were necessary (in one form or another) because it previously
didn't handle the full messiness of namespaces properly. I realized that
when I tried using an XSLT null transform to generate text output from
XBIS. The change in emphasis to a focus on maintaining the canonical
form of documents is just because the Infoset has more stuff thrown into
it than I'm comfortable with handling, in particular everything that
depends on validation.
BTW, my comments on the XSLT handling were only in reference to the
Apache Xalan JAXP implementation shipped with JDK 1.4.1/1.4.2. I assume
other JAXP implementations handle things correctly and don't rely on
optional features.
- Dennis
Scott Wiseman wrote:
>
>Maybe too many changes.
>
>-----Original Message-----
>From: Dennis Sosnoski [mailto:dms@sosnoski.com]
>Sent: Wednesday, June 16, 2004 11:52 AM
>To: XML DEV
>Subject: [xml-dev] ANN: XBIS 0.9.5 and articles (binary XML permathread)
>
>I've got a new version of my XBIS (XML Binary Information Set) software
>out at http://www.xbis.org. This has gone through some major internal
>changes to clean up the architecture and to properly handle some of the
>messier issues with namespaces. It's intended that this should be able
>to maintain the canonical form of any XML documents roundtripped through
>XBIS. I haven't tested it with a canonicalization test suite yet, but I
>*do* include a program that does a simple roundtripping and comparison
>that works well for documents without namespaces (the namespace
>"attributes" get reordered in going through XBIS, so a simple
>byte-by-byte comparison fails).
>
>The test programs now include a document size and performance comparison
>with zip/gzip formats. They also use a null XSLT transform for
>generating text output, which has greatly reduced the advantage shown on
>the output side for previous XBIS tests. I'm not sure this is entirely
>fair to XBIS, BTW - the XSLT transform requires that a SAX input stream
>support the optional namespace-prefixes feature (if the parser doesn't
>support this feature, the XSLT implementation just silently ignores the
>exception and generates crap output). This gives the XSLT code the names
>in qualified form, so it doesn't actually have to do any processing - it
>just dumps them directly to the output. The XBIS implementation, in
>contrast, only uses required features of the SAX2 API.
>
>I've also got a pair of articles out on IBM developerWorks XML zone
>discussing the issues and these test results:
>
>http://www-106.ibm.com/developerworks/xml/library/x-trans1.html
>http://www-106.ibm.com/developerworks/xml/library/x-trans2/
>
> - Dennis
>
|
