Comments on VHG DTD 1.0alpha

[John Cowan]

Peter Murray-Rust wrote:

> <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 at 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)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)