[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: *input* filters

Subject: Re: *input* filters
From: "Simon St.Laurent" <simonstl@xxxxxxxxxxxx>
Date: Wed, 03 Mar 1999 09:17:32 -0500
xsl filter input
At 08:37 AM 3/3/99 +0800, James Tauber wrote:
>It occurred to me the other day:
>
>Any reason we can't have *input* filters in XSL, ie some specification of a
>conversion to apply to a non-XML files in order to produce the source tree?

and then James wrote again, in a different message (result-tree vocabularies
and non-XML serialisation):
>I really like being able to specify non-XML serialisation via the result
>namespace.
>
>What I would like to see is people taking existing non-XML formats and
>developing:
>
>    a) a namespace URI
>    b) a DTD representing the existing non-XML format
>    c) an output filter to convert documents conforming to the DTD into the
>non-XML format
>
>We already see this with HTML 4.0 in XT (and others XSL engines?)

I'm deeply concerned that this line of thought is going to make XSL do (even
more) too many things.  I don't think XSL itself should be concerned with
parsing documents or serializing trees.  Putting all that functionality into
XSL builds XSL out into an ever-growing monster that makes enormous demands on
implementors if they even ponder 'complete'.

It seems wiser to go the other direction, and drop all mention of 'XML source
documents' and let the parser handle that.  An HTML parser that generates SAX
events (HEX - http://www-uk.hpl.hp.com/people/ak/java/hex.html) is available,
for example.  Let XSL work on a source tree and a result tree, and leave the
rest of the processing to other processors, whether parsers for reading
documents or document constructors for serializing the tree.

Lest Guy think I'm just writing this for the benefit of someone in marketing,
I've written a much more general piece on this issue, Toward A Layered Model
for XML, available at
http://www.simonstl.com/articles/layering/layered.htm. The
last figure, http://www.simonstl.com/articles/layering/layered3.gif, shows how
non-XML document sources might be intergrated with XML processing. This was
talking more about parsing issues in particular, but an XSL filter (like XT)
could, for instance, fit anywhere in this process.  Multiple XSL filters could
even appear.



Simon St.Laurent
XML: A Primer / Building XML Applications (April)
Sharing Bandwidth / Cookies
http://www.simonstl.com


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.