Subject: Re: XSL and entities From: Paul Prescod <papresco@xxxxxxxxxxxxxxxx> Date: Sun, 20 Sep 1998 14:13:59 -0500 |
Andy Dent wrote: > > At 11:50 +0800 20/9/98, James Clark wrote: > >G. Ken Holman wrote: > >> XML ---XSL--> FooML ---FooXlate--> foo > > >This is the right approach. To make this work smoothly > ... > >Then you can translate using XSL to foo and the XSL processor can > >automatically give you foo instead of FooML. > Umm, as you've read before I'm struggling to absorb all of XSL and so my > comments should be taken in the very tentative sense I write them: > > Doesn't your 'automatically give you foo' only apply if foo is a textual > file format? I don't see why. After all, FooXlate is a Java package (in our examples, using Java processors) whose only responsibility is to take in XML "events" (or an XML grove) and *do something* (i.e. output text, binary, create windows, whatever). > I think you forgot to clarify that distinction, which would lead people > into the same failure of understanding in which I wallowed for a couple of > weeks. > > If foo is something like > - binary metafiles or Macintosh PICTS > - Windows or Mac GUI output (screen or print) > then you still need a foo renderer. Rendering is a completly different issue. Of course if foo is a binary format, then you must invoke something that understands it in order to render it. But you could also ignore the binary linearization defined for the language and go directly to the data structures or API calls, if those are avaiable. For example: <HTML:HR/> --XSL--> <WMF:LINE width=... height=...> --XML_2_WMFDisplay--> WmfMakeLine( width, height ) Note that the second part need never be actually created explicitly as a text file. The mere act of telling XML->WMFDisplay to make an "WMF:LINE" element would trigger the API call. > In our case, with our report-writer, I'm not really writing an XSL > processor according to (brief) tradition but something that takes XML+XSL > and generates its internal data. It can then render Win or Mac GUI output > as well as HTML (3) and RTF. Right. That's fine. > An approach closer to yours would be if I rewrote our engine, say, as an > RTF parser and then wrote an RTF XSL namespace which could be used with any > standard XSL processor to produce the RTF to feed into our rendering engine. No, Ken/James proposal is merely that you continue doing what you are doing, but a) make your proprietary formatting objects explicit through an NS decl b) make your rendering component mroe reusable by turning it into a generic consumer of XML tree construction events. > The reasons for not doing this are: > - I need an embeddable engine in C or C++ that can be included in a > commercial product, and I don't think there's one out there for XSL I don't understand this point. How can you do something with XML+XSL without an XSL processor? > - writing our front-end as an RTF parser would be a damned sight harder > than the current approach of parsing XML (with xpat) and a little bit of > XSL. You should certainly NOT write an RTF parser and use RTF as the protocol for moving data between an XSL processor and your app. That would be the opposite of what we are trying to accomplish and describe. James and Ken discussed that possibility because some people *need* something like RTF for existing business reasons. You clearly do not. Paul Prescod - http://itrc.uwaterloo.ca/~papresco It's such a Bore Being always Poor LANGSTON HUGHES http://www.northshore.net/homepages/hope/engHughes.html XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: XSL and entities, Andy Dent | Thread | Re: XSL and entities, Andy Dent |
Re: XSL and entities, Andy Dent | Date | Re: XSL and entities, Paul Prescod |
Month |