Lists Home |
Date Index |
- From: Clark Evans <firstname.lastname@example.org>
- To: "Matthew Sergeant (EML)" <Matthew.Sergeant@eml.ericsson.se>
- Date: Fri, 05 Feb 1999 15:54:40 +0000
"Matthew Sergeant (EML)" wrote:
> I guess what I should have said was "Why not use CSS then". If we're
> talking about an XSL that doesn't do transformations then it's CSS you
> should use.
I'm not suggesting that the weakend XSL woudn't do any
transformations, only that the transformations it does
be based upon a stream rather than upon an object.
If this dosn't make sence, then I'd like to hear more.
What I'd rather not see is a "single" language which
defines XML->HTML mappings where an intermediate
form could increase reusability. Thus,
| -> (XSL) -> HTML
XML -> (XTL) -> XML -> (XSL) -> XML
| -> (XSL) -> PDF?
DOM, Server | SAX Client(s)
Side Processing | Side Processing
* Ordering | * Filtering
* Table of | * Formatting
Contents | * Contextual Linking?
* Other "shared | * Other "individual
and information | preference-oriented
generating | stylistic operations"
Mathematically speaking, I'd like to see SAX as
a sufficient condition for XSL processing, where
I'd like to see a full-blown DOM implementation
used when it is a necessary condition for XTL.
This way items like a table of contents, sorting,
and other commonly used transformations can
be seperated from the customized, style oriented
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)