Re: *input* filters

Subject: Re: *input* filters
From: "Simon St.Laurent" <simonstl@xxxxxxxxxxxx>
Date: Wed, 03 Mar 1999 09:17:32 -0500
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