Re: Comments on June 8 draft (long)

Daniel W. Connolly (
Wed, 14 Jun 95 16:30:46 EDT

In message <>, Joe English writes:
>[ BTW, Dan -- did you get the plaintext copy I sent you?

Yes. But I haven't submitted it because:

1. IETF guidelines say the TOC goes after Status and Abstract,
2. Convention says Terms goes right after Intro, not at
the end.

#1 is up to you. I'm fixing #2. I'll have another .tar.gz in a few
minutes incorporating the latest typos and editorial changes.

> It's not on yet. I put it at
> <URL:>
> in case anyone is looking for a copy. ]

That's still linked from the HTML page I maintain.

>[ BTWII: I've been toying with a LaTeX filter too,
> and have a (IMHO) nicer-looking PostScript version
> partially ready; let me know if you're interested. ]

Sure! What's the URL?

Anything not metioned here was incorporated as requested:

>2.2.1. Data Characters, p. 8:
>| Note that the terminating semicolon is only necessary when the
>| character following the reference would otherwise be recognized
>| as markup:
> ^^^^^^
>Should read "would otherwise be recognized as part of the entity name".
> ^^^^^^^^^^^^^^^^^^^^^^^

Same difference. I'll pass on this one.

>4.7 Phrase Markup, p. 24, 2nd paragraph:
>| User agents must render highlighted phrases distinctly from
> ^^^^
>| plain text. Additionally, <EM> content must be rendered as
>| distinct from <STRONG> content, and <B> content must rendered as
> ^^^^
>| distinct from <I> content.
>The "must"s here make "lynx -dump" and other HTML-to-plaintext
>formatters nonconforming HTML user agents. Was this intended?

Er... well... yes. There used to be a distinction between HTML level 0
and level 1 for this, but it went away. By the way: doesn't lynx
do _em_ and *strong* ???

>4.7.1 Idiomatic Elements.
>[ Question: why isn't <DFN> in the DTD? ]

See the archives -- long time ago. Mosaic 2.4 didn't grok, as I
recall. A related thread is begins with:
whither <u>...</u>?
Corprew Reed

.. though I can't find specific discussion of <DFN> in there. But
I remember testing it and finding spotty support at the time.

>6.4. Fragment Identifiers, p. 31, 2nd paragraph:
>| The meaning of fragment identifiers depends on the media type of
>| the resource containing the head anchor. For `text/html'
>| resources, it refers to the <A> element with a NAME attribute
>| whose value is the same as the fragment identifier. The matching
> ^^^^^^^^^^^^
>| is case sensitive. [...]
> ^^^^^^^^^^^^^^^^^
>If %HTML.Recommended; is on, then NAME attributes are IDs,
>so in this case the matching should *not* be case-sensitive.
>This could cause problems:
> <A HREF="#foo"> ... <A NAME=foo>
>will *only* work if HTML.Recommended is *off*. I've seen
>lots of documents that use lowercase anchor names; are they
>going to have forward-compatibility problems?

Err... good catch. I'm changing the DTD -- getting rid of %linkName.
When SGML IDs are introduced, the name of the attribute will
change to ID.

By the way... Roy Fielding suggested getting rid of the METHODS
attribute of the A and LINK element. I'm game for it. In fact,
I can imagine getting rid of URN and TITLE too. Any thoughts?

>9. Terms.
>Under "element", "end-tag", "markup", and "start-tag",
>the term "descriptive markup" should be "generic markup"
>according to the official SGML terminology.
>(FWIW, I happen to like "descriptive" better. It seems
>more, er, descriptive.)

BZZZT. I quote from the holy script:

4.306 start-tag: Descriptive markup that identifies
the start of an element and specifies its generic
identifier and attributes.