Advisory Committee:
Participating Experts:
Apologies:
GK proposed that the next call be held on 2006 July 05.
Neil Bernstein told the committee that Michael Moodie was retiring from NLS after 32 years of service. June 23 will be his last day. Dave requested, and everyone seconded, that the Zed Advisory Committee wish him well.
Markus presented issue 45 "bridgehead not allowed in div", and issue 117, "support namespaces in dtbook extensions." Both issues have been discussed via email without an agreed solution.
James developed the proposed solution to issue 45: "Per the comments in the DTD, bridgehead 'may occur only subsidiary to one of the hierarchic elements.' (that is, level 1, 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." James felt it would not be good practice to use many bridgeheads to compose one long document, but we are not discussing the proper use of bridgehead. We are also not discussing if we should drop bridgehead from the dtd. George noted that we are not the "tag abuse police". We only "put together guidelines, and bridgehead is a good addition which allows books with a 'flaky' structure to use bridgehead."
The proposed solution discussed is: "The answer here 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."
This issue came from work on the MathML extension. The namespace allows hooks to alter the content model. The current specification does not deal with namespace issues arising from extensions and xml is not a "namespace aware" world. In xml, namespaces are attributes, and it is possible to put the namespace anywhere in the document. Should we allow namespaces as xml attributes only on the root or anywhere in the document?
Markus noted that it would be nice to have all xml information appear at the root of the document so that we would know what type of document we are facing.
Dave noted that we are discussing a relatively short term fix until we move into a namespace aware world. What are we trying to help in terms of processing? Are we talking about players? Markus replied that we are mostly talking about an authoring environment.
Dave sees this as a two step process, 1) parsing and validation and 2) rendering by the reading system. Since DTD are not in the namespace game, the only time we are interested in DTD is when we parse and validate a document. Rendering has nothing to do with the DTD. The only time we have namespaces is during the parse phase.
Markus stated that we have to address namespaces. James noted that there are reasons to have namespace attributes for a document engine to see. We need to provide some way to validate namespaces with the dtd.
Markus: The 2005 specification disallows the use of dtd faulting. The extension must physically appear in the instance. If the instance contains the extension, the extension grammar would be prefixed and appear in the document as well as the namespace declaration.
James: We don't have any way to indicate at the top level that a prefix means a certain namespace. For block and inline, we use external block or external inline, and an internal subset to define an entity to add to block or inline. We also need an attribute to add the xml namespace and stay consistent.
Markus allowed that the solution was messy, but this is how the W3C addressed this issue in dtd-land, and we are following the same principles as the W3C.
Dave asked what would happen if an xml validating parser and saw the attribute, i.e., would this instance show up as valid? Markus replied that the instance would show up as both dtd valid and namespace well formed.
Dave would like to move away from DTD's. He feels that we need to make it clear in the specification that this is a kludge, and that we are mixing two worlds that don't mix nicely.This is a known area of weakness in DTD's and in the future we will be moving to schemas.
Markus will update the issues document with the proper wording.
Resolution of the rest of the issues is required for the release of ZedVal. The committee began discussing individual issues which was not the intended purpose of this call. Markus suggested setting the end of June as a deadline to resolving the rest of the issues, and James suggested that we devote an entire call to this.
Lynn will be back from holiday and able to join the call on June 27th. Not many of the issues relate to the Structure Guidelines.
George received an email from RNIB regarding how to put together a technical directions summit. He envisions 20-30 people attending the summit. The technical directions summit will address the direction that DAISY should be taking. Four or five people would talk to industry representatives from companies such as IBM, Microsoft, Adobe, and Apple, regarding where they see things going, especially in our domain. Markus and George will be in New York with IDPF this month. IDPF is looking at adopting DAISY navigation and DTD for their work. George will recruit a handful of people to put together an agenda for the summit.
Tentatively, the Technical Directions Summit will be organized at RNIB in Cambridge the week of October 23, 2006. The Zed Committee meeting would follow immediately after.
Originally, the advisory committee was approved as a 9 member panel with voting privileges. The Chair would rotate, and Lloyd or Neil would take over the position in September 07. Currently, four members are assigned by NLS and four members are assigned by DAISY. Due to the change in maintenance agency, should the Advisory Committee Terms be updated? We must consider the appropriate participation by all organizations. The current Advisory Committee Terms and description of how committee is composed is on the NLS site. Lloyd will send the site address to the list, and Laurie and George will post on the DAISY site.
Time: 9:00 – 10:10 EST
Venue: telcon
Scribe: Laurie Sherve
Last Edited: 2006 June 07
Status: Version 1