[brailleblaster] Re: xsl and xslt
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Wed, 15 Aug 2012 07:49:54 -0500
This sounds great. I would like to add that we want to display and edit
NIMAS natively, but we do not want to hardcode NIMAS structure, element
names, attribute names, etc. I still think that some kind of virtual
machine which integrates displaying and editing is the way to go.
On dynamic translation, I think this should be something the user can
activate if she wants it. It should show the translation of the text in
the current text node in a box. the trranslateString method can be
called at each keystroke. It will do line breaks as appropriate. I think
that dynamic translation might be a bit dangerous, because a user may
not realize that she has to do a complete translation before embossing
or saving. The Emboss Now! menu item is supposed to do a translation if
there is none. Dynamic translation should turn off the translated flag.
I am thinking of two kinds of editing. First is editing of the original
file. This will be done in the Daisy view. Second is editing of the
Braille. This will become active after a translation with formatFor utd.
It should be used only by transcribers or other very knowledgeable
persons. Of course it is done in the Braille view. If a person is
reading the Braille trranslation and notices things like spelling erors
these should be corrected in the original document. This will require a
way to switch back to the display of the original document in the DAISY
view. We should caution people not to try to fix things like spelling
errors by editing the Braille. I know from my experience running a
Braille transcribing operation that this is a very bad idea.
Back-translation is too unreliable to be depended upon, although the
tables for some languages work well in back translation. This includes
U.S. English, German, Hungarian and French.
Just trying to cover all bases.
John
On Wed, Aug 15, 2012 at 11:59:29AM +0000, Keith Creasy wrote:
> That is my understanding and I am starting to think that we need to formalize
> our internal document model and the process because I'm not sure wea are all
> on the same page on this.
>
> I'll work on something to present to the group for discussion because I don't
> want any valuable developer time spent going down the wrong path. Mostly we
> are fine but a few things probably need to be clarified and and agreed upon.
>
>
> Keith
>
>
> -----Original Message-----
> From: brailleblaster-bounce@xxxxxxxxxxxxx
> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J. Boyer
> Sent: Wednesday, August 15, 2012 7:55 AM
> To: brailleblaster@xxxxxxxxxxxxx
> Subject: [brailleblaster] Re: xsl and xslt
>
> I think there are some misunderstandings or maybe some imprecise use of
> language. liblouis does nothing to a documment when formatFor utd is
> specified except add <brl> subtrees containing the braille translation and
> synchronization information and adding a <meta> tag to the <head> node with
> information about the Braille. Documents are not converted to U TD. It is
> added by liblouisutdml.
>
> When Braille is edited in a document to which UTDML has been added,
> BrailleBlaster should move the modified Braille to the original document with
> markup indicating that it is not to be retranslated but simply copied into
> any Braille output. If the Braille is new, that is all that needs to be done.
> If it is a modification of the translation of something in the text, then
> that portion of the text will have to be marked up to show that it should be
> skipped when any future translation is made. The document can then be saved
> in its native format by simply dropping the <brl> subtrees. I think NIMAs has
> the kind of markup required.
>
> John
>
> On Wed, Aug 15, 2012 at 11:38:28AM +0000, Keith Creasy wrote:
> > I agree that XSLT may be useful but I don't think we want to convert NIMAS
> > to UTD unless we can easily convert it back with no loss of data when the
> > NIMAS file is saved. What might work is to do the editing using a UTD
> > document and then update the text elements in the NIMAS file, however this
> > would have to be done with great care.
> >
> > Keith
> >
> >
> > -----Original Message-----
> > From: brailleblaster-bounce@xxxxxxxxxxxxx
> > [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of François
> > Ouellette
> > Sent: Wednesday, August 15, 2012 7:24 AM
> > To: brailleblaster@xxxxxxxxxxxxx
> > Subject: [brailleblaster] Re: xsl and xslt
> >
> > XSL-FO is indeed about formatting output. I was referring to XSLT which is
> > a different beast. I still think we could make use of it in pre-processing
> > XML content that has a well-defined format like NMAS or epub. As mentioned
> > before, we could for example transform NIMAS documents into basic UTD for
> > BB.
> >
> > F.
> >
> > On Tue, Aug 14, 2012 at 11:34 PM, John J. Boyer
> > <john.boyer@xxxxxxxxxxxxxxxxx> wrote:
> > > Ok. I did some checking. What I'm talking about is xsl-fo,
> > > xsl-formatting. There is an O'Reilly book called xsl-fo by David Pawson.
> > > It is available from Bookshare. It is copyrighted, so you have to be
> > > a member. xsl-fo does specify how things are to be displayed and printed.
> > >
> > > John
> > >
> > > On Tue, Aug 14, 2012 at 10:49:52PM -0400, Fran ois Ouellette wrote:
> > >> John: XSL is the language and XSLT is the transformation process.
> > >> It is supported in java and we can also use Saxon or other libraries.
> > >> All you have to do is provide the xsl template file and the input
> > >> XML file to be transformed and you get the output. For example, we
> > >> could have a full UTD file processed to extract the text part and
> > >> braille part with XSLT instead of XOM and get the outputs we need with a
> > >> XSL template.
> > >> Or extract a NIMAS document and turn it into UTD without the
> > >> braille part. It is that simple!
> > >>
> > >> F.
> > >>
> > >> On Tue, Aug 14, 2012 at 10:21 PM, John J. Boyer <john@xxxxxxxxxxxxxx>
> > >> wrote:
> > >> > xsl is not xslt. I am asking about using xsl to specify how an
> > >> > xml file should be displayed. Isn't that what it is intendedd
> > >> > for? xsl is not a transformation language. sxlt is.
> > >> >
> > >> >
> > >> > John
> > >> >
> > >> > On Tue, Aug 14, 2012 at 10:03:59PM -0400, Fran ois Ouellette wrote:
> > >> >> John: XSL is a stylesheet language meant to translate XML into
> > >> > almost
> > >> >> anything you want, even plain text. But it is usually used to
> > >> >> create XHTML from XML with transformation rules. For example
> > >> >> what I was talking about earlier was to turn the NIMAS XML into
> > >> >> simpler elements names that would be closer to UTD.
> > >> >>
> > >> >> F.
> > >> >>
> > >> >> On Tue, Aug 14, 2012 at 9:03 PM, John J. Boyer
> > >> >> <john.boyer@xxxxxxxxxxxxxxxxx> wrote:
> > >> >> > Isn't xsl intended to deswcribe how things should be displayed?
> > >> >> > I always thought it was to xml as css is to html. It would
> > >> >> > enable us to display any xml file natively with proper layout
> > >> >> > and fonts, etc. That would leave editing. I think that
> > >> >> > transforming one xml flavor to another should be avoided,
> > >> >> > because we then have the problem of transforming back.
> > >> >> >
> > >> >> > John
> > >> >> >
> > >> >> > --
> > >> >> > John J. Boyer; President, Chief Software Developer
> > >> >> > Abilitiessoft, Inc.
> > >> >> > http://www.abilitiessoft.com
> > >> >> > Madison, Wisconsin USA
> > >> >> > Developing software for people with disabilities
> > >> >> >
> > >> >> >
> > >> >
> > >> > --
> > >> > John J. Boyer, Executive Director GodTouches Digital Ministry,
> > >> > Inc.
> > >> > http://www.godtouches.org
> > >> > Madison, Wisconsin, USA
> > >> > Peace, Love, Service
> > >> >
> > >> >
> > >
> > > --
> > > John J. Boyer; President, Chief Software Developer Abilitiessoft, Inc.
> > > http://www.abilitiessoft.com
> > > Madison, Wisconsin USA
> > > Developing software for people with disabilities
> > >
> > >
> >
>
> --
> John J. Boyer; President, Chief Software Developer Abilitiessoft, Inc.
> http://www.abilitiessoft.com
> Madison, Wisconsin USA
> Developing software for people with disabilities
>
>
--
John J. Boyer; President, Chief Software Developer
Abilitiessoft, Inc.
http://www.abilitiessoft.com
Madison, Wisconsin USA
Developing software for people with disabilities
Other related posts:
