Re: XSL and entities

Subject: Re: XSL and entities
From: Andy Dent <dent@xxxxxxxxxxxxxxx>
Date: Sun, 20 Sep 1998 23:58:31 +0800
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 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

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.

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.

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.

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
- 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
Andy Dent BSc MACS AACM, Software Designer, A.D. Software, Western Australia
OOFILE - Database, Reports, Graphs, GUI for c++ on Mac, Unix & Windows
PP2MFC - PowerPlant->MFC portability

 XSL-List info and archive:

Current Thread