Z3986 Issues

Currently, the pagenum element includes an attribute @page that indicates the type of page. This attribute can have one of three values: "front", "normal", and "special". Comments in the DTD indicate that these values are tied to the character content of the element itself: "front" [is] for roman-numeral pages at the start of a book, "normal" [is] for pages identified by arabic numerals, [and] "special"' [is] for all other kinds of pages." The Structure Guidelines, however, indicates that "front" pages are those that occur in the frontmatter: "page='front' is used to mark the page numbers used in the front matter of most books (most often roman numerals but sometimes arabic). Regardless of the type of page numbering used in the book, pages located in the front matter, preceding the body, should be marked up as page='front'." So the issue here is which of these definitions of "front" is correct: does "front" indicate the character content of the pagenum (roman numeral), or does it indicate the structural location of the pagenum (in frontmatter).

Most producers and developers understand @page="front" to mean "roman numeral". In addition, the Structure Guidelines description does not make sense: why should the location of the pagenum determine the value of @page for front matter pages but not for any other kind of page in the book? That a page is part of the front matter is self-evident from the location of the pagenum element within frontmatter. For these reasons, the DTD comment should be taken as accurate and the Structure Guidelines should be revised to match this.

This issue arises because of flaws in the whole pagenum/@page structure. If @page is to be used to signal the character content of the pagenum, then the values should perhaps be "roman", "arabic", and "other" -- this would be clearer. That said, there is also the question of why this attribute should be present at all, since the data it provides is redundant. Improving the data model for pagination should be a future direction for the specification.

James' resolution was adopted with 2 outcomes: 1) an update to the SG; 2) a future requirement. Marisa is sending a followup email regarding page numbering schema. There is not any input yet regarding page numbering schemes in other countries.

Some sections not well formed: Part II(c): Inline Elements and Part II(d): Tables, h1 followed by group of h3's.

I am a member of the MathML-in-DAISY WG.

I am validating the fallback MathML example book. To do this, I am mimicing the action of a Basic MathML player: 1) start with the sample book in the MathML-in-DAISY spec (MathML Modular Extension Example 1); 2) transform the DTBook file with mathml-fallback-transform.xslt to produce a non-MathML DTBook file; 3) replace the original DTBook file with the transformed file. The result should validate.

Unfortunately, we have a few errors in the example book, which I am repairing. However, my repaired files don't validate, due I believe, to some issues with ZedVal. I will be pleased to send you the files so you can reproduce the issues.

Issue 1
filename: C:\MathML-in-DAISY\revised NonMathML Official Example\nativemathml.xml
line: 1
problem: A validation error occurred: Attribute "xmlns:m" must be declared for element type "dtbook"..
Conclusion: ZedVal isn’t recognizing standard XML namespace attributes.

Issue 2
filename: C:\MathML-in-DAISY\revised NonMathML Official Example\nativemathml.opf
line: 53
problem: A validation error occurred: bad value for attribute "media-type".
Explanation: The media-type for mathml-fallback-transform.xslt is set to application/xml. The XSLT spec (http://www.w3.org/TR/xslt) says to use application/xml or text/xml, so the media-type is correctly given in the opf.
Conclusion: ZedVal should recognize application/xml or text/xml as valid for XSLT files.

Issue 3
filename: C:\MathML-in-DAISY\revised NonMathML Official Example\nativemathml.opf
line:
problem: manifest illegal files.
manifest file listing is incomplete/listing files that are not part of DTB.
File C:\MathML-in-DAISY\revised NonMathML Official Example\mathml-fallback-transform.xslt is listed in manifest but not part of DTB.
Explanation: The XSLT file is included in the metadata but does not otherwise appear in the DTB.
Conclusion: ZedVal does not inspect the metatdata when checking usage of files listed in the manifest.

Issue 4
filename: C:\MathML-in-DAISY\revised NonMathML Official Example\nativemathml.opf
line:
problem: mime-file mismatch.
manifest mime declaration doesnt match actual file type.
unknown mime type on member with mimetype application/xml.
Conclusion: Same as Issue 2; ZedVal doesn't recognize application/xml as valid for XSLT files.

Issue 5
filename: C:\MathML-in-DAISY\revised NonMathML Official Example\nativemathml.ncx
line:
problem: dtb:maxPageNumber value is incorrect.
the content of dtb:maxPageNumber does not correspond to the highest page value in the NCX.
expected number: 0.
Explanation:. The page number appear to be correct in the NCX and DTBook files.
Conclusion: ZedVal doesn’t appear to be correctly checking the page numbers.

The Zed committee felt that this issue should be addressed in the next issue of the spec.

This is not an issue with the specification, rather known issues with table renderings in IE. Refer to css on daisy site as a model. Kathy to rewrite the dtbook css to try to solve the problem.

Change the comment in the next release of the DTD.

WCAG_2005.xml in the sample content zipfile (WCGxml.zip) is not valid. It references dtbook-2005-2.dtd.

DTD changed to correct version.

Specification should be modified in Section 5.1

Agreed Solution:

Remove the style attribute from the coreattrs entity and the attrsrqd entity. The stylesheet entity is no longer referenced and will be deleted.

This will be revised in the next version of the specification.

Noterefs and annorefs in SMIL files: It is strongly recommended that links are applied to the media objects (normally audio) for all noterefs and annorefs [1]. Why not apply the link to the wrapping par?

	<a href="#note_id">
		<par>
			<text/>
			<audio/>
		</par>
	</a>

	<par>
		<text/>
		<a href="#note_id"><audio/></a>
	</par>

The 2005 DTD tries to avoid allowing nested prodnote elements. The content of prodnote is 'flow' which includes 'inlinenoprodnote', and there is a comment in the DTD saying that prodnotes should not nest. But prodnotes can be nested since 'flow' includes 'blocknoimggroup', which includes 'dtbookblocknoimggroup', which in turn allows the prodnote element.

Agreed Solution:

No change in this minor version upgrade. This issue is placed in the future direction category, and will be addressed when we move from DTDs to a schema language.

Agreed Solution:

No change in this minor version upgrade. This issue is placed in the future direction category, and will be addressed when we move from DTDs to a schema language.

Agreed Solution:

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

Agreed Solution:

Use the term "XML Declaration" instead of current wording at 2.1 (line 108). Use "Document prolog" instead of "Document tagging content" in heading 2 text.

Agreed Solution:

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

The DTD currently has two elements that are meant to support modular extensions to the DTD: "externalblock" and "externalinline"(see 4.2.2 of spec). Unfortunately, these can't be used by elements that can be used in both block and inline elements such as the proposed <math> element to support a math extension to DAISY. There be something like a "externalblockorinline " element to support math and other "flexible" elements.

Agreed Solution:

To have four parameter entities defined that provide means to allow an individual book to modularly extend the content models:

Revise documentation comment (section 3) in the DTD.

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

Agreed Solution:

Add the %externalNamespaces entity to the %coreattrs entity to, in alignment with namespace aware contexts, allow namespace declarations or redeclarations to appear on any element node in the document entity. Consequently, the Dtbook DTD itself does not enforce root element declaration; this is instead considered a constraint that if wanted should be enforced by higher level rulesetting instances.

Note that the DTD defaulting prohibitions as per section 16.1 of the Z3986-2005 specification apply to this construct. Further and consequently, documentation must explain that the basic use pattern of the %externalNamespaces entity is for example to expand "xmlns:m #IMPLIED" into the attlist.

Revise documentation comment (section 3) in the DTD.

What kinds of change in a grammar results in a change of the namespace URI?

W3C recommends that specifications that define namespaces should explicitly state their policy with respect to changes in the names defined in that namespace [1],[2].

This policy can be published as a separate document at the zed site, and thus does not necessarily impact the spec document (nor erratas).

[1] http://www.w3.org/TR/webarch/#versioning-xmlns

[2] http://www.w3.org/2001/tag/doc/namespaceState.html

We will create a namespace URI policy with the next revision of the specification. However, it will be done sooner if required by a modular extension.

The z2005 defines non-ambiguous mime-types for each allowed member type. However, how does one create a nonambigous mimetype field in a http request where one wants to reference an entire DTB? How does this correlate to the anonymous mimetype of opf (text/xml)?

One extension needed for DTBook adoption in Japan is Ruby. Suggestion that a WG be put together to look at formally adopting an extension using the Ruby module in XHTML 1.1[1], alternatively ITS [2].

[1] http://www.w3.org/TR/ruby-implementation/

[2] http://www.w3.org/TR/2006/WD-its-20060222/

The problem is that DTDs and ENTs can either be referenced locally or via the canonical http URI: both are currently allowed by the spec. It is confusing and misleading to say that these are considered members only in one of the cases.

Suggestion that the spec be changed via an errata stating that that entity references in the System ID field in an XML document prolog are _not_ considered part of the DTB, irrespective of whether the SID URI is local or remote. This non-membership as a consequence means that the entities should not appear in manifest, which also means that the table in section 3.3 needs modification [1].

This change is in harmony with the non-PSVI-infoset-augmentation policy adopted for z2005 [2].

[1] http://www.daisy.org/z3986/2005/z3986-2005.html#Manifest

[2] http://www.daisy.org/z3986/2005/z3986-2005.html#FileConform

Agreed Solution:

The z3986-2005 spec explicitly allows for multi-content-doc DTBs. Therefore: clarify that the idref attribute is a URI; both in DTD and in SG. SG to clarify that both internal "#idref" and external "doc.xml#idref" are allowed. DMFC provided schematron schema will include value validation.

Proposed Solution

The DAISY Board felt that the IFLA should create global unique identifiers for DTBs. DAISY will submit this as an issue to the IFLA.

That the content model for the showin attribute is changed from showin (xxx|xxp|xlx|xlp|bxx|bxp|blx|blp) #IMPLIED to showin CDATA #IMPLIED

Reason: The current content model is associated with the traditional formats for the visually impaired user, which makes the showin attribute unsuitable for other formats, e.g. ebooks, audio etc. With the proposed change, the values showin="audio-synth-speech" showin="audio-human-speech" showin="ebook-html ebook-rtf" showin="audio braille large-print" showin="pdf" showin="latex" showin="pda" etc, etc would be available. Certainly, main stream publishers would benefit from a less restricted model for the showin attribute. It would also be possible to localize the attribute values, some examples in Norwegian could be showin="lydbok" showin="punkt" etc The disadvantage is that mark-up would be less predictable. However, with the upcoming XSLT 2.0 specifications this should not be a problem during transformation. The template below is an example of how selection based on the showin attribute could be done:

  <xml:space="preserve">
<xsl:template match="*[@showin]" priority="10"> 
<xsl:param name="output-format"; as="xs:string" select="'_UNDEF'" tunnel="yes" /> 
 <xsl:choose 
  <xsl:when test="not(matches(@showin,$output-format))"> 
    <xsl:comment> 
       The element <xsl:value-of select="name()" /> has been removed. 
    </xsl:comment>
  </xsl:when>
  <xsl:otherwise>
   <xsl:next-match />
  </xsl:otherwise>
 </xsl:choose>
</xsl:template>

Agreed Solution:

No changes to the showin attribute. The showin attribute is being marked as deprecated in the 2005-2 version of the DTBook DTD. Following more modern conventions that have evolved since showin was added some years ago, the committee's intention is for output format-specific information to be maintained in separate namespaces, a.k.a. extension modules.

That another attribute is defined in the DTD, named notshowin (or something appropriate). This attribute should be available on all elements that can carry a showin attribute. The effect of the attribute is that the element is ignored during transformation for the format(s) specified in the transformation. Model: notshowin CDATA #IMPLIED

This would allow for the following mark-up:

• <prodnote render="optional" showin="braille">This is the prodnote when creating braille from this XML-file.</prodnote>
• <prodnote render="optional" notshowin="braille">This is the prodnote when creating anything but braille from this XML-file.</prodnote>
• <prodnote render="optional" showin="#all" notshowin="audio-human audio-synthetic">This is the prodnote for anything but audio related output.</prodnote>
• <prodnote render="optional" showin="audio-human">This is the prodnote for DTBs narrated by a human person.</prodnote>
• <prodnote render="optional" showin="audio-synthetic">This is the prodnote for DTBs narrated by a machine.</prodnote>

Agreed Solution:

No addition of a notshowin attribute. The showin attribute is being marked as deprecated in the 2005-2 version of the DTBook DTD. Following more modern conventions that has evolved since showin was added some years ago, the committee's intention is for output format-specific information to be maintained in separate namespaces, a.k.a. extension modules.

We need to create guidelines on how organizations should clearly mark opening announcements so that they may be replaced.

There was a spirited discussion about throwing out the pre element, because it was not semantically rich; it was visual presentation only. We now believe we need something.

does the job only because of established precedence in HTML.

Would <div class="code">code work? Not without processing applications being told what to do.

div xml:space="preserve" is the least semantically clean option with the current vocabulary.

If this does not work, what do we need to do to resolve the problem?

Introduce at least one new element.

Proposal: <programlisting>

A ProgramListing is a verbatim environment for program source or source fragment listings

Formatted as a displayed block. This element is displayed "verbatim" whitespace and linebreaks within this element are significant. ProgramListings are usually displayed in a fixed width font.

Other markup within a ProgramListing is recognized. I'm lost for an element name for the more general case.

Agreed Solution:

extend the %coreattrs entity with the xml:space attribute.

The spec says (4.1): Two metadata items must be present in the <head> of compliant textual content files, contained in a element: dtb:uid and dc:Title.

1. The DTB ns prefix is undefined in the spec.
2. The DTD (comments) only require one, the title. quote. As a minumum the dc:title meta is required.

Encourage inclusion of additional Dublin Core and DTBook metadata to make more useful the DTBook as stand-alone content. end quote.

Note also the case difference. The DTD is lc, the spec is camel case.

Agreed Solution:

1. fix case diff in DTD comments by using 'Dc' instead of 'dc' at line 656
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 suggested to use is "http://purl.org/dc/"

bridgehead not allowed in div

Agreed Solution:

Use %docblockorinline to add bridgehead to div content model

I would like to propose a change to the ANSI/NISO Z39.86-2002 and -2005 standards regarding the section entitled "Audio File Formats."

I believe it is in the best interest of the DTB community for the standards to be codec agnostic. By specifying codecs, the standards lock out the use of newly developed or less expensive compression schemes that could benefit DTB producers and consumers. These include the open source Ogg family of codecs (including Vorbis and Speex) and the extremely efficient AMR-Wideband+ codec, which has won a number of codec "cook-offs" for speech sound quality and which has been chosen by the National Library Service for use with its upcoming Digital Talking Books.

In place of specifying particular codecs, we may wish to have the standard specify only a set of qualifying quality factors, such as ease of navigation. NLS has developed a list of nine quality factors that we used in making our decision to go with AMR-WB+. I would be happy to share these with the committee as a starting point for issuing this erratum.

Please let me know how we should proceed in handling this issue.

Use: doctitle marks the full title of the book, including any subtitles, <frontmatter>. By convention <doctitle> should appear. Contrast with covertitle.

From the Structure Guidelines: Markup: Doctitle should be the first element inside the front matter and can be used to quickly identify the book. It thus serves the same function as does the title printed on the cover of the print book and should contain the same information. Note "printed on the cover", which to me implies covertitle?

and covertitle from the dtd

Use: covertitle is the short title of a book, often found on the spine. It may be the same as the doctitle.

I can't find covertitle in the Structure Guidelines.

The comment is made though, when a book contains a title which is abbreviated on the cover, with the full title presented on the title page, <covertitle> should be used to mark up the abbreviated title, and <doctitle> to mark up the full title as shown on the title page.

Question: covertitle, is it the abbreviated form, doctitle being the more complete version?

"type" is advisory content MIME type of the target, see [RFC1556];

at line 1668 Reference is to RFC 1556. Wrong? Should be to [RFC2046] as per other uses of %ContentType;

#IMPLIED Editorial change only?

Agreed Solution:

The reference will be changed to RFC2046.

add xml:space to div attlist

Agreed Solution:

extend the %coreattrs entity and %attrsrqd entity the with the xml:space attribute.

Rewrite attribute lists of code and samp to prevent duplication of @xml:lang

ELEMENT frontmatter ((doctitle | covertitle), docauthor*, (level | level1)*))

This from the structured guidelines review Lynn and Brandon have done. Basically to ensure the document title is required in frontmatter?

Agreed Solution:

Modify the content model to the following: (doctitle,covertitle?,docauthor*,(level|level1*))

Title attribute does not allow an id

How to use code and samp as block level element

This is a documentation issue.

Agreed Solution:

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

There is no expanded XHTML file for current specification and DTDs. This was a part of the 2002 version. How can we provide the equivalent or better documentation?