dtbook-2005-1 errata proposal

Per the comments in the DTD, bridgehead "may occur only subsidiary to one of the hierarchic elements." (that is, level1, etc.) It currently can only be a direct sibling of these elements. We could just add to the div content model, if we feel that doesn't violate the intent of bridgehead. div content model would then be:

(%block; | %inlineinblock; | doctitle | docauthor | covertitle | bridgehead)+

At that point, we might as well use %docblockorinline; which expands to the same thing, and hence divs become exactly the same as levels (minus the hierarchy).

The content model provided does not mandate doctitle, and suggests that doctitle and covertitle are mutually exclusive alternatives (not true). Suggest this content model instead:

(doctitle+, (covertitle | docauthor | level | level1)*)

This mandates that doctitle be the first element. Current content model is:

(doctitle | docauthor | covertitle | level | level1)+

Add reference to %coreattrs in title attlist. (dtd line 1763)

The problem here is the result of the expansion of the %flow entity in the DTD. %flow represents the (almost) full set of inlines and blocks for those elements whose content models encompass both (e.g., prodnote). %flow is made up of %inlinenoprodnote and %blocknoimggroup, which themselves include %externalinline and %externalblock (respectively). Therefore, if an extension declares the same element to be in both %externalinline and %externalblock, any element using %flow will have duplicate items in the content model.

To fix this, we can follow Neil's suggestion of having three entities for external element inclusion: %externalinline, %externalblock, and %externalFlow. These are referenced as follows:

1. New entity %inlineFlow -- just like %inlinenoprodnote, but minus %externalinline
2. New entity %blockFlow -- just like %blocknoimggroup, but minus %externalblock
3. Content model for %flow uses %inlineFlow, %blockFlow, and %externalFlow
4. Content models for all places where %externalinline is used add %externalFlow as well
5. Content models for all places where %externalblock is used add %externalFlow as well

A similar fix will need to be made to %flownopagenum, which uses %inlinenopagenum.

The answer here, as indicated above, is to add another entity -- %externalNamespaces -- that is defined by the extension within the internal DTD subset. The content would be the attribute declaration for a namespace prefix declaration. This is added to the attribute list for <dtbook> so that the prefix can be referenced throughout the dtbook document.

(The other change we might want to include here would be dtbsmil changes to support namespaces as well: use of the systemRequired attribute, for example. Note that the latest version of the MathML extension use this. Is that out of scope for us?)

Two things needs to be decided. First of all, what is the intention of the 2005-1 DTD (and the 2002 version) regarding the idref attribute? Is it an IDREF or an URI? The upcoming version of ZedVal currently treats the attributes as IDREFs.

For an updated DTD, there are two main options:

1. Make idref attribute IDREF The links will be validated by the DTD itself, but there will be no support for inter-document links, such as in a book containing one DTBook file per chapter. Are there any multi-document books available today?

2. Make idref attribute %URI This will support inter-document links, but the link between a noteref and its note will not be validated by the DTD.

The basic question here is: Should inter-document references between noterefs and notes be supported for multi-document books? As the size of a DTBook document increases, the performance of players degrade. Hence there might be a reason to allow for multi-document books. But if a noteref is in one document and the corresonding note is in another document, when following the note reference (and going back), a player must either:

a. Keep both documents in memory, which would lose some of the benefits of having more than one textual document.

or

b. (Re)parse the document when switching, which could lead to performance degradation.

idref is not a good name for an attribute that is not of type IDREF. One option would be to rename the attribute to href or similar if we are going for the %URI version to support inter-document links. This change would of course not be backward compatible.

Prodnotes may be used in inline (as well as block) context, and since prodnotes may contain inline content, they are easily nested. It would be fairly straight forward to disallow the direct nesting of prodnote elements (see below), but is there any benefit in doing that? Indirect nesting would still be possible (i.e. via another element, such as div).

1. New entity %dtbookblocknoimggroupnoprodnote, like %dtbookblocknoimggroup but no prodnote
2. New entity %blocknoimggroupnoprodnote, like %blocknoimggroup but with %dtbookblocknoimggroupnoprodnote instead of %dtbookblocknoimggroup
3. New entity %flownoprodnote, like %flow but with %blocknoimggroupnoprodnote instead of %blocknoimggroup
4. Change content model of prodnote to %flownoprodnote

This change would not be backwards compatible since documents having directly nested prodnotes would not validate against a modified DTD. However, I suspect very few (if any) documents have directly nested prodnotes.

Suggested change: None for now. This issue is better solved using schemas.

"Once you go inline, you can never go back"

The prodnote and imggroup elements can be used in an inline context, but may contain block elements.

One way to solve this would be to have separate elements for block and inline use. Another way would be to switch to a schema based description of the content model where the content of a element may depend on the context.

Yet another way for fixing this issue would be to only allow prodnotes in block (or flow) context. Then, a prodref element is introduced to point to a prodnote, just like a noteref is pointing to a note. In all inline context, only prodref would be allowed. Now only the content model of caption in imggroup would have to be changed from flow to inline and all block elements in inline context would be gone. This change would however be a major change in the way prodnotes work, so I don't think this change should be made in an updated DTD.

Suggested change: None for now. This issue can better be solved in the next (schema based) version of Daisy.

RFC1556 "Handling of Bi-directional Texts in MIME" is not the primary reference for the generic mime 'type' attribute, although 1556 is still the correct reference for expression of charsets/bidi.

The reference should be changed to RFC2046 as suggested.

xml:space is a core xml attribute, and should be allowed on any element, by extension of the %coreattrs entity.

1. fix case diff in dtd comments at line 656; case to use is dc:Title (only first char in localname uppercased) and no other.
2. fix the 'As a minumum the dc:title meta is required.' comment at line 1144 to include all minimum requirements
3. Add dublin core normative spec reference to both these spots. The URL to use is "http://purl.org/dc/"

change ATTLIST for bdo to allow xml:lang and not allow lang.

The part of the very verbose and sometimes redundant comment prose referred to starts at 2.1 (line 108) and refers to what is canonically dubbed the "XML Declaration" (production 23 of xml spec).

Propose change to use the term "XML Declaration" instead of current wording.

Heading 2 text needs fixing too; currently "Document tagging content". Suggest using "Document prolog" instead.

When moving to schema, we should make sure to use inline prose as little as possible; maintaining local versions of externally defined constructs is not a good use of time.

remove this comment and add external reference when doing the coreattrs append described in #i5068.

It is my opinion that we should not expand the options for the showin attribute at this time. What are the use cases for it? Will we be using showin as part of the "braille in DTBook" work? How are alternative (conditional) presentation versions handled in the Open Document Format or the Microsoft-ECMA document format?

If I had thought more carefully about this DTD as it currently exists, I would have recommended that showin be required on <book> and that "blp" be the recommended value for it.

We have to decide whether dtbook should be seriously considered as a universal e-book format, or whether it should specialize in being the standard for accessible e-books.

I have no response to issue 93 at this time, but it would be similar to what I am attaching below for 92. Perhaps I need to become more imaginative, but I feel that we need to implement what we have, as well as solve the math inclusion problem, before we can open up more and more dtbook presentation choices.

Remove the style attribute from the coreattrs entity.

Causes backwards incompatibility: yes, this is a content model restriction