Include semantic markup for multiple purposes (navigation, show/hide, backtranslation etc.)

[wfree-aph]

As a reading system developer, the document should include semantic markup so that multiple use cases have the potential to be addressed.

Detail:
Braille users want many different options including enhanced navigation and the ability to show/hide different elements of the document. There are also braille producers that may potentially want the ability to work backwards from the braille document. All of these options require that the document has rich semantic markup that identifies the elements we want to show or hide or use for navigation. Additionally, the reading system could backtranslate and then retranslate elements if braille code switches are identified using markup as well.

Proposal:
The document should include semantic markup that identifies at least the following:

• Emphasis changes
• Braille code changes
• Braille grade changes
• Print and braille page numbers
• Headings
• Table formatting

[wfree-aph]

At the meeting: potential suppression of blank lines and that a new issue should be made for this use case.

The more markup that is added to the file, the less like a traditional BRF file it looks. The more markup we add, the harder it could be for a transcriber to specify exactly what they want.

Discussion of preformatted text with spaces and tags around it. Could also have the tagging of braille code, and you might have a different braille translation. Could solve both kinds of issues.

Avneesh, is there specific semantic markup that is needed for braille that is not already used in DTBook or HTML specifications. It would be good to find this out now for our next phase. An example is two kinds of paragraphs (blocked and indented) but there's only one kind of paragraph in DTBook and HTML.

This leads to the need for classes. Knowing these exceptions would help us know if an existing standard will be a good model.

[mattgarrish]

Starting a review of the issues to see how they match up against EPUB, HTML, and DTBook, and I agree it's hard to answer issues like this until we know more specifically what needs to be handled and how.

In general, though, I wouldn't expect the need for rich markup to be an impediment to any of the formats. All have rich base grammars for documents. DTBook can also be extended to add new elements and attributes. HTML (and by extension EPUB) has custom elements, but these are a little trickier to implement (involves scripting). Both also could utilize the class attribute.

The DPUB ARIA module also defines a number of publishing structure roles, such as for pagination.

EPUB has also extended XHTML in the past using namespaced elements, although this is not considered good practice if browsers are expected to handle the content (and isn't compatible with regular HTML).