Advisory Committee:
Participating Experts:
Apologies:
GK proposed that the next call be held on 2006 August 02.
There are no outstanding issues relating to the DTD. Lloyd, Markus, James, and Linus will fix the DTD to incorporated the resolutions to the issues.
The easy way to test dtbook-2005-2.dtd would be to use the 2001 to 2002 xslt. This is not yet complete. If we do wait for the xslt, then we are testing both the DTD and the xslt.
George thought that the dtbook-2005 -2 could be used to validate content on the web site, for example, the MS FrontPage and World Cultures book. Markus noted that since there were backwards incompatible changes in the dtd, we should make sure that only these backwards incompatible changes break, and make sure they do break.
Although previously discussed, Dave disagrees with releasing the new version of the DTD into "the wild" to find problem areas. James suggested that perhaps the technical developments group could find the bugs, and we could do the testing later. However, Markus saw a problem if anyone downloaded the dtd before testing, and James agreed.
Dave and Markus agreed that we needed to develop a test suite to challenge the DTD, and write each test for a specific purpose, to test the "corners" of the DTD. It is important to define what is being tested, for example, the differences between dtbook-2005-1 and dtbook-2005-2.
James felt that we don't have to exercise entire DTD, but Dave added that we must test all changes made to the DTD. For example, we would have to test all valid and invalid permutations of frontmatter.
Markus noted that the test suite would be different from the test suite for zedval.
Looking forward, George wanted to know if the tests could also be used with a future schema version? Since the schema will redefine the constraints, it would be possible to use rewrites of the test files. The test files are something that we can build on.
James agreed to help design the architecture for testing the DTD, but wanted to know what the testing would look like?
There is a java utility library that could do a part of this job. It would be possible to write a wrapper to perform each test. Dave currently has a batch script for testing now. James did not see the need for a big architecture since we had a small number of changes, but Dave thought that we should think longer term. For example, it would be easy to test only 5 items, but more cumbersome to test 500 items. For 500 items, the tests should be automated and output to a log file. If this were designed now, it could be used long term for other testing.
Markus - We need to come up with a scheme to identify each test case.
George is in agreement. James will to identify areas to be tested, George will find resources to create a testing environment, perhaps a batch file to test each case, and add the pass/fail metadata in the dtbook doc itself.
Dave has 128k xml test suite that hit every element. It will be wrong with respect to current dtd.
The math group wanted something concrete in the September time frame. If -2 is not available, this will be problematic to the MathML working group, and -2 has to support what math needs. Could the Math group be used for part of the testing?
Markus thought that we can finish testing by the end of August, and include the math group to make sure that mechanisms used for math will work with the revised DTD.
Dave felt that we needed another extension so we can prove it works with more than just math. Perhaps create a dummy DTD fragment with say two elements for this proof.
Changes need to be made to the Structure Guidelines. Lynn will make a list of changes that need to be made. The errata proposal web site has notes for changes, and Markus instructed that she did not need to include anything that was not in the notes, or obvious to her. Lloyd volunteered to help interpret everything. Lynn will send out a link to the current Structure Guidelines to the xml techniques and technical development lists and ask if people have any comments or recommendations.
Regarding the extended documentation of element semantics and content model, Depending on the changes that James makes, Dave may not be able to generate automatic documentation from the revised DTD. It would then be a matter of hand editing the existing generated files to make the changes. It would be important to note which changes impact the content model.
The goal of the Technical Directions summit is to accomplish goals to move the standard into the future. There are several difficulties coordinating a technical directions summit:
Dave noted that we are starting from the wrong point. The Board of Directors and member organizations should state what they want from DAISY, and we should concentrate on giving them what they want. One way to accomplish this is to disseminate an RFE, or Request for Enhancement, to allow DAISY members to tell us where they would like us to take DAISY.
James agreed with Dave, that technically we can do anything if we had the time and money. One problem is that we are presenting a constantly moving target to our members. For this reason, there is no pressing need for something new, and this could be an acceptable outcome of a technical summit.
Lloyd however, felt that it depends on the scope of the e-books that we are producing.
Markus thought that an RFE process is a good starting point, and we needed more types of input from different stake holders. He would also love to approach interest organizations that are not key in our current strategies, i.e. the dyslexic. DAISY is not driven by needs of the dyslexic user group. DAISY could ask cognitive scientists for key inputs needed to produce a technical specification needed for this user group. This concept could be extended to interested organizations.
DAISY has been bad at addressing the needs of the dyslexic, and 80% of full member patrons are dyslexic. The Board supports addressing the needs of the dyslexic, and is emphatic about addressing the needs of the mainstream population. Lloyd felt this should be a universally designed system.
If the Advisory Committee has a face-to-face in October, we will have not collected the information in three months. Marisa pointed out that we will have collected enough information to have an idea of the areas of focus.
It is possible to could expedite the information gathering process through interfacing with the technical staff from different organizations. The difficulty is how to ask about technical directions for DAISY without steering them.
George posed the question, does the Advisory Committee want to meet face-to-face?
Markus would like to meet to talk about the future of the standard and the implementation of the 2005 standard. George wanted to know if it was urgent to decide on either the W3C schema or Relax NG. James pointed out that since we don't know where we want to go, this is an implementation detail and therefore not in scope.
Marisa is interested in where DAISY will go with smil. smil is looking at a new spec revision, and her profile was submitted yesterday.
The RFE could generate information for the board, and a subset of the Advisory Committee.
A meeting may not happen in October if the justification is not there. Dave indicated that the Board had requested the Technical Directions Summit.
Markus requested if Dave would send his relax ng notes to the list. There are many places in the workflow where schemas are needed instead of DTD's.
We need to propose a way forward to the board. The Technical committee could meet to put together the beginning of roadmap based on what DAISY members want.
The "type" attribute in smil is an error in smil.
Time: 9:00 – 10:10 EST
Venue: telcon
Scribe: Laurie Sherve
Last Edited: 2006 July 10
Status: Version 2