Stuff going into W3C CVS, DOM2.dtd

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