Re:Standard API to XSL processors

>James has claimed that the DOM is not suitable to be the internal
>representation for one random access application - the XSL processor
itself.

I'm not sure I want to ask "why not". I do want to remind folks that if the
DOM doesn't provide something that XSL needs, and you expect that other XML
applications may also need it, you should liaise with the DOM WG to explore
solutions and alternatives. If you've got a divergence of basic assumptions
about the conceptual structure of XML that this doesn't resolve, get the
Infoset or Syntax WG's involved and fold their conclusions back into both
DOM _and_ XSL.

The DOM is not unchangable. It can be extended. It can even be corrected,
if you can demonstrate that something it now does is a serious problem. And
I think the DOM developers see XSL as a useful testcase; if anything,
there's a wish that XSL had been further along and in a better position to
provide active feedback as the DOM evolved.

If W3C comes out with a set of XML standards that don't fit together -- not
necessarily perfectly, but without undue force-fitting --  someone didn't
do their job.

______________________________________
Joe Kesselman  / IBM Research
Unless stated otherwise, all opinions are solely those of the author.



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list