I like this. When I earlier suggested that we avoid 'schema' it was because
the word was already in use and could cause confusion. There is - I think -
an implicit assumption that namespace declarations can point to 'schemas',
and these are not *necessarily* (though possibly) the things we are building.
The idea of Type Definition on a per-element basis is something I already
use a lot and this helps to formalise it. It also goes well with the
modularity of the ATTLIST and ELEMENT declarations in well-formed documents
- i.e. you can declare *some* elements and *some* attributes.
Assuming for the present argument that PEs are not included, and reserving
judgment on entities (though my current feeling is exclusion) everything
left is either an ELEMENT or an ATTLIST (I think). Conventional DTDs do not
provide for relations between elements or attributes so we can tackle this
on a per-element basis. [Another problem I had with schema is that to some
people it suggests relations between elements, beyond those provided by the
contentSpec.]
>
>There is a sense in which "Document Type Definition" is misleading for
>things like CALS tables or MathML. They aren't definitions of document
>types, rather they are definitions of element types. "Extensible Type
>Definition" makes this clearer.
>
Agreed. The DOCTYPE statement does not define the document type [Eliot
Kimber pointed this out ?here?]. And the DTD has no formal mechanism for
adding human- or machine-readable semantics.
XTD seems fine to me, but I'm not passionate. It fits well into the current
S->X shift.
P.
Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg