output method: all or none. (was Re: HTML output method: out

David Carlisle:
>Nikita Ogievetsky:
> >The other funny thing about html method is that XSLT parser generates a
semi
> >valid document that it can not read back.
> >Seems to me that if there are fancy output methods there are should
> >corresponding fancy input methods.
> > (i.e. XSLT parser should be able to read HTML document if it was
produced by
> > another conformant XSLT parser.)
> I don't see how that could be possible in general. The result tree can be
> linearised in any way the application can provide. HTML, text, sound,
> ... Some of these forms may not be too suitable for being read back in.
> In the case of HTML it ought to be possible, all you need to do is find
> an HTML (rather than XML) parser that will present a SAX interface to the
> XSL engine.
This is good for general HTML.
But for documents (quasi-HTML) produced with XSLT transformation a much
simpler solution will work:
Send HTML document through a filter prior to parsing it with XML parser.
Filter should:
1) expand Boolean attributes : replace <option selected/> with <option
selected="selected"/>
2) escape characters within <script> and  <style> tags and "&{" combination
in attribute values
3) add end tags to empty elements: change <br>,<hr>, etc into <br/>, <hr/>
etc.
    ( Why was there a need to do the opposite: most HTML browsers have no
problems reading empty elements with end tags. Are we saving characters
here?)

Are we missing DHTML output method that would live unescaped onEvent ( event
handler ) attributes? :)
Some problems should also be in CSS style attributes... (other then &{)

Once started moving this way should we finish?
Although I would have been happy having just xml output and homemade regular
expressions on top of it.
>Roll on xhtml, save us from this madness!
I agree with you, but afraid it will be a long weight...

Nikita Ogievetsky
http://www.cogx.com


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