Re: A's content model

Terry Allen <terry@ora.com>
Date: Wed, 21 Sep 94 21:24:10 EDT
Message-id: <199409220122.SAA28254@rock>
Reply-To: terry@ora.com
Originator: html-wg@oclc.org
Sender: html-wg@oclc.org
Precedence: bulk
From: Terry Allen <terry@ora.com>
To: Multiple recipients of list <html-wg@oclc.org>
Subject: Re: A's content model
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: HTML Working Group (Private)

| In message <199409212335.QAA25549@rock>, Terry Allen writes:
| >I've just been writing a piece in HTML and had trouble with
| >anchors using Dan's 3 DTDs (or my 3in1.dtd derived from them).
| >The content model for A assumes content
| >and will not allow an omitted end tag (from html0.dtd).
| ><!ENTITY % A.content   "(%heading|%block|%text)+">
| ><!ELEMENT A     - - %A.content -(A)>
| >However, the only way an A works properly as a target in Mosaic
| >is if it is empty (has no end tag).
| 
| Not true. A works properly as long as there's something between
| the A start tag and the A end tag. The idiom:
| 	<A name="noContent"></A>
| excercises what I'd like to call a bug in Mosaic.
   [ ... ]

What is the bug?  I'm trying to create targets for A
links earlier in the same document, and I can't do it with:

| Our first inclination was to simply write:
|  <DT><CODE><A NAME="4MvVSWBSRpF84aK"></A>href</CODE>
| but this excercises the aforementioned "bug" in Mosaic.
| 
| Perhaps we need a NOTE in the spec about this...

Well, if one wants to write docs that work right with Mosaic now, 
they will not conform to the present DTD on this point.  That 
seems wrong for a DTD meant to document current practice.

It seems to me that we must make legal the only form that Mosaic 
accepts for A as a target, and warn users that parsing against
the DTD will not assure them that A's intended as links actually
have content, as is desired.  

| >(However, as NAME will eventually become an ID, the value of NAME
| >given here, starting with a number, will become dysfunctional,
| >because IDs must begin with a letter; how about knocking that 4 off 
| >the start of it and any others of the sort?)
| 
| I don't think NAME will ever become an ID attribute. It's just
| not practical.

So we'll never be able to use SGML's ID/IDREF functionality?

| Perhaps we'll deploy ID attributes (and call them ID, not name).

I would deprecate the creation of attributes named ID that were defined
as CDATA (as NAME is now).  That could create a lot of confusion.

| I think the A tag is badly overloaded: it's the source of an anchor,
| or the destination. It's used for footnotes, references within a
| document, references across documents in the same "corpus," references
| across corpuses, etc.
|
| I'd prefer to replace A as the destination of a link by allowing any
| number of elements to take an ID attribute (ala HTML+).  I think it
| would be useful to have some sort of link that uses ID/IDREF
| attributes so that an SGML parser could be employed to check those
| links. It might also be useful to indicate whether a link is to
| something in the same "corpus" or to something in a vastly different
| context, though it's not clear that we need special markup for
| that. Perhaps that's the job of the author.

So you want links to CDATA values and links to ID values?  
If you just define HREF as an IDREF, then allow any element to have an ID, 
you have the problem solved, except that it makes obsolete docs with 
NAME values that start with a number, due to woodenheadedness on the part 
of the SGML committee.

On the other hand, maybe HTML is a good opportunity to force change
in this ridiculous restriction!

| Anyway... none of this will happen in the near term...

Certainly true about CDATA/ID.

| >So the content model should be changed to:
| ><!ELEMENT A     - O %A.content -(A)>
| So you're advocating allowing folks to omit the </A> tag.
| Murry, Eric Sink, and myself have all said "yuk," but nobody
| has raised any technical objections.

Well, my point is a sort of technical objection to *not* 
omitting the end tag:  if you don't allow its omission, you can't parse
the format Mosaic requires.  I'm not defending the design or
Mosaic, only trying to validate my docs.


-- 
Terry Allen  (terry@ora.com)   Editor, Digital Media Group
O'Reilly & Associates, Inc.    Sebastopol, Calif., 95472