Re: *input* filters

I wrote:

>>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?)


And Simon wrote:

>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'.


None of what I'm suggesting in the quote above has to be inbuilt into XSL
engines.

I fully envisage that both input and output filters will be separate
applications to the XSL engine.

As far as I can tell, this is quite in line with your layered model, Simon.

There are obvious advantages to avoiding the need for an input filter to
serialise its result as XML only to have it parsed by the XSL engine or for
the XSL engine to serialise the result tree only to have it parsed by the
output filter.

One way to avoid these things is for the XSL engine to drive the filters on
the basis of namespace URIs provided in the stylesheet. This is already what
the XSL WD suggests for output.

James
--
James Tauber / jtauber@xxxxxxxxxxx / www.jtauber.com
Associate Researcher, Electronic Commerce Network
Curtin University of Technology, Perth, Western Australia

Full-day XML Tutorial @ WWW8 : http://www8.org/

Maintainer of : www.xmlinfo.com,  www.xmlsoftware.com and www.schema.net





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