| XML input specification@ | Rules files | Java code | Usage | TODO list | Implementation Issues | ...XML input specification
This is the schema and documentation for brxml, a braille targeted XML.
html file. The schema is available for download, and a minor example, brxml.rng and brxml.xml are available in the download directory.
A little explanation is in order, as to why I picked this list of elements, what the implied semantics mean etc. So, starting from the top.
brxml. Wrapper or document element. I gave it a namespace almost for the sake of it. Don't forget that xml:lang is valid here, and will be required if you want automated processing. Two children, meta and body for metadata and the document content.
meta. The page element indicates the required page dimensions (in cells) and allows for an optional header text. An optional page number is available, for the formatter to embed a braille page number when the content is layed out.
body. Wrapper for the document content.
body. Body content is one from a list of elements:
-
para. Block level content. Same definitions as a block in xsl-fo. Content to be laid out in the page progression direction. For Western use this is top to bottom. For others it isn't. Hence the funny definition. (@TODO work out how to address non-top to bottom layout if neede). para element can be default layout (line one in cell one, remainder of block starting in cell 1 - I assume 1 based counting, not zero). Content can be centred in the line (indicates minimum space of 3 cells either side) or can explicitly specify the indents using the start and end attributes. AFAIK this fully specifies block content for braille usage. Unless you know any different? Additionally (not sure if its necessary) you can specify that white space should be preserved or collapsed.
-
literal. The lit element caters for content pre-translated by a professional transcriber and laid out (formatted). This is to allow more complex braille inclusion than the engine can cater for. This content will go straight through to the formatter.
-
breakHere to enable forced breaks in a block progression direction. I'm sure other classes of break may be needed. This is the only one I felt necessary.
-
code. The first inline element offered. There for computer coded content.
-
em. Emphasis. Again an inline.
-
??. @TODO. I feel sure that a switch to grade one braille will be needed, which will require an inline span type of element. I haven't added it yet.
That's it for the present. I haven't coded for all these elements as yet. Still working on the Sax interface.