RE: XSL processor wanted ...

[keshlam@xxxxxxxxxx]

Since there are SAX-to-DOM and DOM-to-SAX modules available, you should be able
to fit an XSL processor into either environment. There may be some overhead if
its native representation is different from the one you're going to, but that's
always true.

If DOMImplementation acquires a factory method for Document (discussed but still
undecided), it'll be possible to create a new Document in the same
implementation as an existing one. But _someone_ has to pick an
implementation...

Outputting with configurable encoding: Given that you can generate DOM and/or
SAX, isn't that just a matter of plugging in an encoding module as the next
stage of processing?

Making an XSL engine completely independent of particular DOM features ought to
be possible in the long run, though I'm not sure whether DOM Level 1 has
everything you'd want. Of course specific processor implementations may get
better performance by being aware of extensions added to specific DOMs; as an
analogy, consider that IBM's XML4J parser will take advantage of some custom
hooks in the document model if they're available, but can output to a completely
standard DOM as well.

I believe LotusXSL, with external SAX adapters and output generator added (the
latter may be supplied by the parser package?), would come pretty close to what
Miles has asked for... but Scott would be the right person to ask about that.

Re subclassing the DOM: I can't vouch for other implementations, but mine's set
up to allow subclassing of any actual node type. The trick is that you also have
to subclass Document to re-route its factory method to the subclass. Of course
if you break the node's behavior in your subclass code, that's Not My Problem;
with power comes responsibility. (You can't usefully subclass Node because
inheritance in Java doesn't work that way, and I wasn't willing to switch from
inheritance to delegation to support it.) This hasn't been intensively tested
yet; caveat usetor and be sure to report bugs.

(Another option in my DOM, if you're willing to accept something nonstandard, is
to hang additional objects off the "userData" hooks. That's sometimes an easier
alternative than subclassing, and I've nominated it for possible addition to the
DOM spec.)

______________________________________
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