Define and implement architectural changes for supporting multiple standards
Getting multiple spec support in an easily-maintained and yet non-code-duplicative way is likely to require some fundamental architectural changes
Fix Exception propagation
Generally, exception handling would benefit from a brush-up
Consider the use of Schematron
Schematron embedded in RelaxNG provides a very powerful assertion-based language layer on top of the pattern-based layer of RNG.
In many (or all) ways, Sch is a more transparent and easily maintained alternative to the XSLT test processor as used in zedval2002
Optimize interdoc link checking
Interdoc links need speed optimization
Fulltext considerations
We are chartered to implement support for fulltext DTBs in zedval2005.
Dont we already have that?
What tests, apart from DTD validation and smilref validation, are required?
Consider porting of classes to/reuse of classes from org.daisy.util
In terms of context neutral classes used, there should be no functionality overlap between the zedval packages and the org.daisy.util package (currently living at the DMFC CVS)
Classes that can be considered are for example SMILCLock, Fileset, ParserPool, RNGSCHValidator, CatalogEntityResolver
A move like this may require neutralization of some zedval base classes (consider for example the difference between the ZedFile hierarchy and the org.daisy.util.fileset package)
Migrate to SDK1.5 and JRE5
Java5 is the current runtime version, sporting many features of benefit for XML-related apps, such as JAXP1.3 bundling Xerces on top of the factory heap.
GUI
A GUI is not on our charter right?. GUIs have been provided by third parties.
[JP]Cleanup of file-handling.
Specifically, cleanup of file open/close
code to repair bug #948316 (too many open files), but there's probably
some other stuff we could do here.
DistVal
[JP]Is this in scope or not? There's definitely a need. I
worked out a design for DistVal that borrowed heavily from ZedVal ... it
implemented it as a kind of custom app on top of the ZedVal engine. At
the very least, we might want to keep it in mind when doing the rest of
the ZedVal 2005 work.
[JP]Use of some code from the Apache Jakarta project.
There are some
nice things in the commons[1] project, if you haven't browsed through
there. For example, I think their CLI library would help clean up our
option-handling in ZedVal. I also wonder about tools such as Launcher.
Also, I had thought at one point about using Jakarta's ECS[2] as a
replacement for all those easy-to-mess-up strings in DefaultReporter.
JavaLayer1.0
The Mp3File class of zedval2002 uses some stray classes from what has now become JavaLayer1.0. Migrate to use of their published jar.