Several people did, including myself. The problem is that ALT is never
required in current practice, and thus cannot be required in the 2.0 spec.
Perhaps recommended, but not required.
>>* (LI)+ => (LI)* in OL and UL: why?
>
> The group seemed to agree that the degenerate case should be allowed.
Conceptually, any list can contain 0 or more items. Both
XMosaic and Lynx appear to handle them correctly.
>>* ADDRESS in BODY comment was marked "Dan?": I don't know what this is
>> supposed to mean.
>
> Hmmm. I wrote that note. Does anyone remember why we discussed ADDRESS
> and BODY?
The only thing I recall about it is the need to have more than one
paragraph within a single Address, and the question was "Why does Dan
disallow P under Recommended?", or something like that.
I can't remember who brought it up.
>>* HTTP-EQUIV and NAME attributes of META were changed from NAME to CDATA.
>> Why?
>
> Someone told me that NAME was just plain wrong, and I did as I was told.
> Anyone remember who it was?
Probably me. Terry (I think) brought up the question regarding whether
or not the same name could appear in both HTTP-EQUIV and NAME, e.g.
<META http-equiv="owner" name="owner" content="fred">
and that such a thing would not be legal if the attribute values were
both NAME. However, I may have misunderstood.
The following document passes through the validator:
==========================================
<HEAD>
<TITLE><!-- your title here --></TITLE>
<META http-equiv="owner" name="owner" content="fred">
<META http-equiv="owner" name="owner" content="fred">
</HEAD>
<BODY>
<!-- your HTML test data -->Testing
</BODY>
==========================================
but the parsed output seems kind of strange. Is it correct, Dan?
==========================================
AVERSION CDATA -//IETF//DTD HTML//EN//2.0
(HTML
(HEAD
(TITLE
)TITLE
AHTTP-EQUIV TOKEN OWNER
ANAME TOKEN OWNER
ACONTENT CDATA fred
(META
)META
AHTTP-EQUIV TOKEN OWNER
ANAME TOKEN OWNER
ACONTENT CDATA fred
(META
)META
)HEAD
(BODY
-Testing
)BODY
)HTML
C
==========================================
and the "Elements found" list does not include META.
However, similar output is produced for a normal
<META http-equiv="owner" content="fred">
so this may just be a "feature" of sgmls.
In any case, I asked that the attribute values be returned
to CDATA (as I defined them originally) because I did not want
the syntax of SGML to dictate the syntax of the META names.
However, I could very well be wrong in that regard, and will
agree with whatever the SGML gurus decide is best.
.....Roy Fielding ICS Grad Student, University of California, Irvine USA
<fielding@ics.uci.edu>
<URL:http://www.ics.uci.edu/dir/grad/Software/fielding>