- From: Curt Arnold <carnold@houston.rr.com>
- Date: Tue, 10 Jul 2001 03:14:00 -0500
- To: <www-dom-ts@w3.org>
- Message-ID: <001201c10918$46af1930$7600a8c0@CurtMicron>
I've spent some time tonight walking through generation of the DTD for the DOM 2 family of specs. There are a couple of issues that I ran into: 1. expandEntityReferences, which I had been using as an implementation condition, is used as a attribute in the NodeIterator interface. I renamed the implementation condition to isExpandingEntityReferences in the DTD (not in the schema or code gen yet). Will probably need to rethink the implementation conditions representation, maybe <testCondition property="expandEntityReferences" value="true"/> etc, instead of the existing set of implementation condition elements as there could be a raft of conflicts with DOM 2 loading. 2. TreeWalker defines firstChild and a few other things as methods that are defined as attributes in Node. I've taken a shot at addressing this in dom-to-dtd.xsl (again not in schema or code gen), basically the attribute form is produced and the method form suppressed. As mentioned earlier, I have dropped the RDF and DC namespaces and am using <metadata about="..."/> for data about an external resource. subjects.xsl now produces an a file that will validate against dom1.dtd. dom2-combine.xsl will combine the various DOM 2 Specs (Core, Events, Style, Traversal/Range, Events and HTML) into one dom2-interfaces.xml document that are used in the building of dom2.dtd, dom2.xsl et al. The generated dom1.dtd and dom2.dtd will have defintions for <suite/> and <suite.member/> Whitespace in the generate DTD's are much more regular. DOM 2 artifacts are build identifically to DOM 1, ant dom2-dtd ant dom2-schema ant dom2-interfaces ant dom2-subjects I haven't double checked these on Linux, there is possibility that the directory cases aren't perfect.
Received on Tuesday, 10 July 2001 04:13:50 UTC