[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: XSL and entities


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
Keywords