Comments on VHG DTD 1.0alpha

[Peter Murray-Rust]

Thanks very much for your comments, John.

At 15:02 05/06/98 -0400, you wrote:
>Generic site comment: Fetching TM out of the Symbol font works only
>with browsers that accept the nonstandard "face" attribute of FONT.
>Netscape shows an ä instead, which is very ugly.  I suggest
>"(TM)" as a plain-text workaround, since unlike ® the TM-symbol
>has no legal standing.  (Of course, ™ would be the Right Thing.)

Over to you, Lesley :-)

>
>I think that the entryID attribute is a mistake.  Even non-validating

<entryID> is an element and can be anything that #PCDATA can accept.  There
can also be multiple entryIDs.  I think you mean the id attribute on
termEntry...

>parsers will still return the correct value for the "id" entry.
>People who want to use IDs that aren't XML Names can **** well
>encode them.

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. 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.

Of course it can be relaxed later. But tightening up is always more
difficult. So the authors are going to have to find a way of uniquifying.
term1, term2 ... is the simplest. Do the current authoring tools support
uniqueness?

>
>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...

>
>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.

I also agree with you about extended. I think the whole Xlink spec is too
text-oriented. I've argued to make it more general. 

	P.

>
>An excellent piece of work!
>
>-- 
>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)
>
>
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

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)