[brailleblaster] Re: xml processing block diagram
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Thu, 4 Oct 2012 11:09:51 -0500
I'll add another input to the block diagram for utd files, which are
basically working files. They will be handled like any other xml file
except that the automatic translation step will be skipped.
The gest way to handle plain text files is to use the translateTextFile
method with formatFor utd. The resultant file will be handled like any
other utd file.
Similarly, the best way to handle brf files is to use the
backTranslateFile method with formatFor utd.
For new files, text can be entered, and when enter is pressed the user
is asked to assign a style to the block of characters. The block is then
places in the parse tree being constructed with the markup appropriate
to that style. The text in each block is dynamically translated in the
Braille window as it is entered.
The block diagram will also have to include handling of file sets, such
as NIMAS and epub. opf and similar files can be handled like other xml
files, so that they can be edited.
John
On Thu, Oct 04, 2012 at 12:05:59PM +0000, Keith Creasy wrote:
> I would think that imported text files would be broken into XML paragraphs.
> This has to be done in some way anyhow. As for new text it is entered in the
> normal way but is stored in memory and when saved as XML. Everything
> internally is XML regardless of how it originated. This makes sense because
> BrailleBlaster is based on UTDML anyhow so at some point that transition has
> to happen.
>
> Keith Creasy
> Software Developer
> American Printing House for the Blind
> KCreasy@xxxxxxx
> Phone: 502.895.2405
> Skype: keith537
>
> -----Original Message-----
> From: brailleblaster-bounce@xxxxxxxxxxxxx
> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of François Ouellette
> Sent: Thursday, October 04, 2012 7:33 AM
> To: brailleblaster@xxxxxxxxxxxxx
> Subject: [brailleblaster] Re: xml processing block diagram
>
> What is the scenario for plain text, imported from a file or new text someone
> will type in from scratch?
>
> Your scenario implies that we open a XML file,
>
> F.
>
> On Wed, Oct 3, 2012 at 9:29 PM, John J. Boyer <john.boyer@xxxxxxxxxxxxxxxxx>
> wrote:
> > Here is how I see an xml file being processed according to the revised
> > framework. This should be considered a block diagram.
> >
> > First, some remarks on the files that will be used. I am assuming that
> > they will be Java properties files, because the information is
> > key-value pairs. I do not see any advantage to using something more
> > complicated.
> > Human readability and writeability is important for developers,
> > because we will have to write some of them and we will have to check
> > that the GUI dialogues are operating properly. Creating and changing
> > properties files with these dialogues will also be much simpler than with
> > xml.
> >
> > Immediately upon opening an xml document is parsed by xom to produce a
> > parse tree.
> >
> > The configuration files indicated in the user's settings are then read
> > and used to begin the construction of a semantic table. This table is
> > used to specify how markup in the document is to be rendered on the
> > screen and how styles are to be associated with markup for editing.
> >
> > Semantic-action files are then read. A file is chosen by looking for a
> > file with the name of the root element and the extension .sem or
> > according to an indication in the configuration files.
> >
> > If the semantic-action files contain XPath expressions as keys these
> > are applied to the parse tree, and the selected nodes are modified by
> > adding an attribute indicating the entry in the semantic table to be
> > used. The value of each key will already have been entered into this table.
> >
> > The keys containing markup in the semantic files are then applied to
> > the parse tree, and a similar attribute is added to the matching
> > nodes, unnless it is already present because it has been added by an
> > XPath expression.
> >
> > This forms the DOM of the document.
> >
> > This DOM is then used to display the document on the screen.
> >
> > Editing can then take place. If the contents of a text node are
> > altered the new contents replace the old. If an element node is
> > deleted its entire subtree is deleted. If a new block of characters is
> > created the user is prompted to asign it a style and a node with the
> > appropriate markup is added to the document at the place where the new
> > block was created.
> >
> > The file will already have been rendered by liblouisutdml and the
> > Braille displayed in the Braille window. If the user is authorized to
> > edit Braille, any editing is highlighted in both the Braille and print
> > windows.
> >
> > When the file is saved the parse tree is massaged to move any edited
> > Braille into the print document with proper markup, to remove all
> > UTDML and to remove the attribute which is used for the DOM> Editing
> > in the print window is handled automatically as part of the conversion
> > of the parse tree to a file.
> >
> > --
> > 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:
