i think this will be an improvement. the Nov 22 spec still uses the
older form, but i'm assuming you and Eric will get it in sync before
the IETF meetings.
>
> >Creating a copy of ISO Added Latin 1 character entity declaration set
> >---------------------------------------------------------------------
> >
> >Why is the HTML spec creating a new character entity set that is
> >basically identical to the ISO set (as far as I can tell) and giving it
> >a different FPI?
>
> With the above clarification, could you "get into the details of
> a suggestion" please?
after discussion with Dave Raggett and James Clark, i stand down from
my earlier misgivings. provided that the idea is still to put À
in the document rather than À or whatever. that way, if i receive
an HTML document, i can process it with MY HTML doctype which i will
create by reading my copy of ISO Latin 1 SDATA entity declarations
in place of the HTML Latin 1. likewise, a document i've produced
using the ISO Latin 1 declarations will be parsable by a system that
uses the HTML declarations.
all i would repeat here, then, is to be sure to change the public
identifier and copyright in HTML Latin 1 and preferably don't use
%ISOlat1; as the entity name to refer to them because it might lead
to unnecessary confusion.
>
> >Non-compliant use of parameter entities
> >---------------------------------------
> >
> >There are several occurrences of non-compliant use of parameter entities
> >in the latest DTD. In brief, you cannot define a parameter entity with
> >"dangling" connectors such as "| FORM | ISINDEX".
>
>
> OK... I'll try to incorporate something like that. But I don't have
> any way to be sure I've gotten it right. Perhaps I'll mail it to you
> so you can run it through a sufficiently anal-retentive parser before
> my next release.
as i've indicated in private email, Exoterica has offered to parse the
DTD through their parser to help catch all potential glitches their
parser notes, also note that anyone with access to Omnimark,
an Exoterica product, could do the same for you (for example, i note
Jeff Suttor mentioned omnimark in his "adding ICADD archforms" mail).
>
> >CDATA terminated by any ETAGO
> >-----------------------------
> >
> >The comment associated with the declaration for %literal; is somewhat
> >misleading.
>
> Please suggest an alternative.
>
In place of:
<!ENTITY % literal "CDATA"
-- historical, non-conforming parsing mode where
the only markup signal is the end tag
in full
-->
i'd suggest
<!ENTITY % literal "CDATA"
-- historical, non-conforming parsing mode where
the only markup signal is the first end tag (for
any element) encountered and this terminates the
<literal> element
-->
of course, this assumes you want to describe what SGML will do.
if the comment is supposed to be describing what browsers do,
then ignore my suggestion.
>
> > Since the use of CDATA for element content models can lead
> >to surprises [I'm glad this is deprecated], I think it's important to
> >make the comment clearer.
> >
> >The fact is that an element whose content model is CDATA is terminated
> >by ANY end tag--even an invalid one! That is, if the string "</"
> >occurs in CDATA content, the current element will be terminated.