Chris Maden wrote:

>[Paul Prescod]
>> In the XSL FO world, it seems that you need to specifically target
>> each disability because the FOs are not designed to degrade.
>
>No, they're not.  Should they be?  Time to drag this out again:
>
><URL:http://www.oreilly.com/people/staff/crism/xsl/audioxsl.html>
>
>What do people think?  I've gotten mixed feedback on it.  Some people
>feel that providing a fallback will discourage real alternate-media
>stylesheets' development, but I observe that those stylesheets are
>almost never developed anyway.
>

    So would this be, for example, a default aural XSL sheet that would take
XFO as input and transform into something to be aurally rendered? If so, I
like it :-)

    This would be accomplished by a client side transformation pipeline.

    I'm completely missing something about this XFO vs CSS debate for aural
rendering. If there exists the argument that:

    XML -> (xslt - server side) -> XHTML + CSS allows better client side
aural rendering than XML -> XSL (server side) -> XFO, then given the proper
XFO generation can;t we just:

    XML -> (xslt) -> XFO -> (xslt) -> XHTML + CSS (???) and get the exact
same aural rendering, assuming that the XML -> XFO xslt doesn't terribly
degrade the XML semantics. Since aural rendering in general will depend on a
reasonable: XML -> XHTML+CSS transformation, what is the difference if there
is an intermediate step which contains XFO? If I can't do an XFO ->
XHTML+CSS transformation it seems that there wound be something badly wrong
with XFO. And if this transformation can be done, then what is the argument
here?

    What am I missing?

Jonathan Borden
http://jabr.ne.mediaone.net



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