- From: Borden, Jonathan <jborden@mediaone.net>
- Date: Tue, 5 Jan 1999 08:12:50 -0500
- To: <www-dom@w3.org>
Lauren Wood wrote: > > What would help would be some idea of the relative importance of things > commonly covered under the term "DTD". ... > > Here is a non-exclusive list: > Validation: > data typing valid (would need to wait for schemas) > this element is allowed here > this document is currently valid > > DTD information (probably to be extended with schemas): > elements allowed within this element (no repetition or ordering info) > elements allowed within this element (with repetition and ordering info) > allowed attribute names for this element > allowed attribute values for this attribute on this element > > DOM Level 1 already has a list of notations and entities. How about (just) a full tree based representation of the data contained in the DTD? rw is preferable. the child elements of a !DOCUMENT node are a tree not a list, but it contains !ELEMENT nodes, !ELEMENT nodes contain a child tree and an !ATTLIST list... RW is best to start because the iterator interfaces should contain the appendChild method > > Then the question as to read-only and read-write comes up. Is read-only > sufficient to start? > > Does the information in the internal subset need to be distinguished > from that in the external subset? yes. DOM <-> text needs to roundtrip with 100% fidelity... this IMHO should be the primary responsibility of the DOM, as well as the ability to create any/all wf / valid XML documents. Issues concerning *behavior* of the interfaces should wait until the interfaces themselves have been defined. Certainly behavior is important for the design of the interfaces but, for example, the issues about schemas should wait because schemas can already be expressed using existing DOM mechanisms. Suppose we are writing a word processor: is it rational to implement the spell checker before the keys are hooked up? > > Any thoughts you have on these sorts of questions would help us figure > out what the minimum useful set of functionality is. The smaller it is, > the faster we can get it done. We can add more functionality later. > >
Received on Tuesday, 5 January 1999 08:15:59 UTC