Lists Home |
Date Index |
- From: John Cowan <email@example.com>
- To: XML Dev <firstname.lastname@example.org>
- Date: Fri, 05 Jun 1998 16:46:16 -0400
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
> Do the current authoring tools support
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
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 email@example.com
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:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)