Subject: RE: XSL processor wanted ... From: keshlam@xxxxxxxxxx Date: Tue, 16 Mar 1999 16:08:31 -0500 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: XSL processor wanted ..., Kay Michael | Thread | Using XML/XSL to access archived da, Sara Mitchell |
Beyond XSL's capabilities?, Blanchette, Larry | Date | RE: How to add a variable/changeabl, Koh, Justin (Intern) |
Month |