> <entryID> is an element and can be anything that #PCDATA can accept.
Sorry, I meant element, of course. Your annotated DTD (which I
worked from) says that the entryID element semantically overlaps
the id attribute of termEntry, and that strikes me as bad; not
fatal, just regrettable.
> I struggled with this one. We have little experience communally of how much
> ID is going to be used in XML.
> The key aspect of IDs is that they must be unique - and parsers must
> report errors here.
Actually, only validating parsers must enforce the uniqueness
and related ID/IDREF constraints. Nitwitted but fast parsers
are free to pretend everything is CDATA, and there is very little
that #PCDATA can do that CDATA can't (external entity references
in IDs? Yuk!).
> This was the bargain I had to make - uniqueness versus
> flexibility of content. It is very important to have handles on the
> termEntrys, so id really forces people to have to do it. (They can't put in
> entailment without it). And remember that the authors will be curators, who
> care about content and robustness and related things. So a unique string is
> not a tragedy.
Sounds like you're making my case here: keep the ID attribute, drop
the sub-element.
> Do the current authoring tools support
> uniqueness?
AFAIK no, but running through nsgmls afterwards isn't *that* hard.
> >When the Itsy Bitsy stabilizes, you may want to use it as the
> >content model for the admin, definition, and note elements.
>
> Indeed. I am also disappointed at the slow progress towards an DTD for
> XHTML...
So am I. There's a stalled project to create an SGML DTD to be
a "static subset" of HTML for writing RFCs, which I tried to revitalize
(so far it's still flatlined) by contributing an XML DTD closely related
to the Itsy Bitsy; it included HTML3.2 table support and some stuff for
HEADs and BODYs.
I promise that I don't really create DTDs as fast as listfolk may be
thinking: I'm drawing on my (all of two months of) prior work here.
> >I believe that you should force (using #FIXED) inline=true for
> >simple links, and inline=false for extended links. This is a
> >general view of mine.
>
> Thanks. Again we have no experience. The simple links are not embedded in
> mixed content, so does it matter? But I can and probably will do it.
type=simple inline=true is the tried and true HTML model, and I think
that a simple link that does *not* link its content is a bizarre
anomaly; one-ended links should be handled as part of the extended-link
model. Likewise, an extended link that does link its content can
be easily created with a locator element referring to self.
-- John Cowan http://www.ccil.org/~cowan cowan@ccil.org You tollerday donsk? N. You tolkatiff scowegian? Nn. You spigotty anglease? Nnn. You phonio saxo? Nnnn. Clear all so! 'Tis a Jute.... (Finnegans Wake 16.5)