Re: FW: XSL - Loss to braille style sheets?

Subject: Re: FW: XSL - Loss to braille style sheets?
From: Paul Prescod <papresco@xxxxxxxxxxxxxxxx>
Date: Fri, 04 Sep 1998 10:56:41 -0500
Pawson, David wrote:
> 
> Possible, as JC suggests using DOM access is viable.
> Why not from within the style sheet? I haven't heard any valid reasons not
> to.
 
Because doing it within the stylesheet using ad hoc scripting will hurt
our long term goal of making Braille access ubiquitous and reliable. If
every author must *choose* to copy and paste in your JavaScript code into
their stylesheet, they will never end up doing so. It's a question of
doing the easy thing for the short term or the easy thing for the long
term.

> > or the OUTPUT of XSL
> No Paul. Contractions need to be applied prior to formatting.
> Having laid out a paragraph on a page, there seems little point in
> contracting (to half the length) then having to format _again_

The output from XSL is not a formatted page. It is a set of formatting
*objects*. I expect that, like DSSSL, those formatting objects will have
no knowledge about the actual layout on a particular screen or page. So
the output of XSL *is* probably the most logical place to apply your
processing.

> Yes, we could apply prior to using a stylesheet.
> Yes, Ecmascript and accessing the source grove via the DOM is viable.
> We then have to ask MS/Netscape etc, to 'fit' the pre-process into their
> model of operation.
> 
>           N O.

The *very existance of the DOM* implies that they are already planning to
give people access to XML source groves. That's what the DOM is for!! So
it is merely a question of asking them whether to implement the existing
standard that they ratified themselves, or invest in a *new* ad hoc
Javascript-in-XML standard. If I had to bet on one or the other, I would
bet on the former.

> > BTW, if you get conversion to braille working as an XSL post-process, then
> > you can plug your post-process onto the back of any XSL spec and open up
> > the web to Braille.
> Our objective.

If a post-process is your objective, then why are you concerned with
ad-hoc in-stylesheet scripting?

> >  On the other hand, if you embed it in particular
> > stylesheets, then only a small fraction of the web will be available in
> > Braille.
> >
> Illogical. In the same way that you couldn't write a stylesheet to present
> any
> web XML document to your tastes.

I don't know what you are talking about. Presumably there is some
reasonable mapping from some reasonable subset of the formatting objects
in XSL to some reasonable subset of Braille. You can choose to code that
mapping once, or you can write a new Braille stylesheet for every document
on the Web.
 
> > Everything I touch turns into Python.
> Python would do the job, but v slowly ;-)

Certainly not slower than JavaScript, which is what you seem to propose.
 
> Sorry to be a bore to you sighted guys.

Your concerns are certainly not boring. I just think that you have the
wrong model for addressing them. Ad hoc JavaScript processing is what you
should be running screaming from. My guess is that this type of ad hoc
processing in HTML pages makes the Web difficult to view for blind people.

 Paul Prescod  - http://itrc.uwaterloo.ca/~papresco

Everything I touch turns into Python.


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


Current Thread