I think that the only reason that I favor CONTENTS over TOC is
that we have already deployed lots of doc with CONTENTS used.
We can probably adapt our browser to use TOC in addition to
the CONTENTS value that we already use, but that won't help
us with respect to other brwosers which won't recognize CONTENTS.
Anyway, I'll think about this some more, and I suspect that others
will try to convince me to bend to popular opinion.
>
> 2. I don't understand how a BOOKMARK is different from an A. I don't
> think bookmarks belong in HTML, actually. So I'd dump this value.
No comment until Dave has an opportunity to comment.
>
> 3. NAVIGATE seems suspiciously like "other." Are you actually using
> it, Murray?
Yes, we are actually using it. It has some of the characteristics
of CONTENTS (for us) but it has other features. In Dave's 3.0 spec,
he had a HELP keyword which he describes as follows:
The link references a document offering help,
e.g. describing the wider context and offering
further links to relevant documents. This is
aimed at reorienting users who have lost their way.
>
> 4. BEGIN.
> >BEGIN
> The BEGIN relationship identifies user-defined start of a
> sequence of documents of which the current document is a
> node. TOP is a functional equivalent to BEGIN when only one
> is specified.
>
> only one what? only one of the two, only one TOP, only one BEGIN?
If only one of the two values is specified. I figured that a
collection of related HTML documents -- like a book whcih hgas
been burst into many files -- might have both a hierarchical
and sequential model woven through. In that case, the TOP
of the tree might also be the BEGIN of the sequence. If only
one is specified, then it means both. Maybe that is not an
appropriate assumption to make. Other feedback?
>
> 5. Document types. I believe these should be left to META for the
> document itself, and that there are so many of them that (barring some
> implementation experience to the contrary) we shouldn't try to identify
> genres like this for the target of links. So Murray, I agree with
> you, we don't need these yet.
OK, I have deleted this list from my proposal -- which I will
repost some time "real soon now".
>
> 6. Related Docs. Here two items seem to me like Nav Nodes:
> Biblioentry and Footnote. Also, while we have BIBLIOGRAPHY and
> BIBLIOENTRY, we have no corresponding GLOSSENTRY, which would be
> just as useful.
I don't see why BIBLIOENTRY and FOOTNOTE seem like navigation nodes.
And anyway, what difference does it make?
I didn't do a GLOSSENTRY, but did a DEFINITION instead. It seemed
to me that a GLOSSENTRY is usually a DEFINITION, but a DEFINITION
is not always a GLOSSENTRY. Maybe we should have both. Comments?
>
> 7. > It is expected that REL=BIBLIOENTRY will be used in
> combination with REV=CITATION to create a link between a
> book citation
>
> and a what? functionally, why do I need REV=CITATION if I have a
> REL=BIBLIOENTRY? just to get back to where I was when I looked
> up the biblioentry?
Oops. Yes, "and a bibliographic entry." Why? I just thought
that searching software might want to locate anchors which
identified themselves as a CITATION. This may not be needed,
as one could use <CITE> to identify the citation. So it seems
true that REV=CITATION is not really needed, and it also seems
obvious that REL=CITATION is useful. I'll leave it in for now,
with a note that "This has questionable value. It may be deleted
at the next revision."
>
> 8. Meta Documents. I understand that you might want some of this
> stuff in linkable boilerplate. (I wonder whether a link to a
> copyright notice counts as a copyright notice proper ....)
> But some of this is clearly meta, such as AUTHOR. This is info
> that should be in the doc, not linked to (it is essential info,
> and no less expensive to put the there in the doc than to link
> to, right?).
The point is not whether one could put info in a document, but
whether it might be useful to have links -- accessible through
toolbar icons -- to lead to these meta documents. I think that
it would be very useful. A link to AUTHOR might be a mailto:...
or an http:... to the author's home page on the WWW.
>
> ========================================================================
>
> Okay, now on to some of the other issues raised in discussion.
>
>
> BANNER. I suspect BANNER could use more empirical discussion, and
> wonder whether it shouldn't be generalized into something more like
> DISPLAYMESOMEHOW. And the present content model
>
> <!ELEMENT BANNER - - %body.content>
>
> allows one to put an arbitrary amount of stuff in a banner. If my
> window is smaller than the content, and I can't scroll down within
> the banner (or can I?), how do I see the end of the banner? if I
> can scroll down, do I get to see there's something beyond the
> banner? how much? can the user override the banner behavior?
> (respondents to this point please name your thread!)
>
> Banner on A would seem pointless; we may want different lists of
> values for LINK and for A. Anyway, I would leave it out until
> we have some experience with BANNER.
I tend to agree, but I think that Dave Raggett needs a chance
to make his arguments.
>
>
> TEMPORAL SEMANTICS. I like Roy's idea of Userselect/Autoentry/etc.
> But I think these may be style sheet semantics, rather than issues of
> content labelling (aka document markup). That said, these are
> vital style sheet issues, and browser developers should be asking
> themselves how they can make these aspects of browser behavior
> accessible to the user (e.g., via a style sheet).
I like the idea also. I haven't thought about how it might
be encoded in HTML, but I tend to think that authors/publishers
should have an opportunity to indicate their preference somehow.
Perhaps users could indicate their preference, through a user
preferences mechanism in each user agent. I don't presume to know
how this needs to be done. I'd like to think about it a bit more
and go back over the discussion. Other input is welcome.
>
>
> VERBS and NOUNS. This aspect of the discussion seems to me to be
> located in the Twilight Zone. The specification of keywords
> involves sentences. The use of any particular character string
> to stand for those sentences is purely arbitrary. If you want to
> quibble about the style of those strings, okay.
I don't want to quibble over verbs vs nouns. I just want a set
of keywords to use, and clear descriptions of their meaning.
Oh -- I also want to continue to use the five keywords that
SCO has already deployed.
>
>
> CLASS and REL. Bert, you might want them both! Think about it.
> Imagine a doc having multiple sets of LINK/RELs.
>
>
> CHICAGO MANUAL. Murray uses as an example a CITATION of the Chicago
> Manual of Style. I deprecate all references to this work. CITATION
> is probably useful nonetheless.
Having reached the opposite conclusion (see above) I wonder if you
could elaborate on the potential usefulness.
>
>
> ==========================================================================
>
> SUMMARY
>
> With a few reservations, I'd like to adopt Murray's definitions of
> keywords under his categories of Browser-defined, Navigational,
> Hierarchy, and Sequence, but eliminate Related Docs and Meta Docs,
> while folding a few of those items into Navigational.
OK, then I need to provide a better explanation of the Meta values.
>
> Of the Other, I am dubious about Banner as presently specified
> (though something of the sort is obviously wanted by some), and I kinda
> wonder if the link to a style sheet wouldn't be better made through
> a processing instruction (it's just what they're for, after all).
The link to a stylesheet might not be a processing instruction.
When it is, it is. When it is not, it is not. My thinking
is that <LINK REL=STYLESHEET is a declaration that the UA
ought to use the stylesheet specified by the HREF value.
On the other hand, <A REL=STYLESHEET is simply a GET and the
UA might decide to launch a special application -- editor --
because it is a stylesheet.
> The Paths values would seem to be parallel to BEGIN and END.
So, PATH and NODE should move into the Sequence group?
>
>
> INCLUDE. From the SGML point of view, sticking includes in structured
> text is a bad substitute for entity management. But we don't have any
> entity management, and no way of declaring entities anyway (unless
> we use LINK, which would be an interesting path ...). So, eyes open,
> understanding that INCLUDE means you can stick a whole book into
> the middle of, say, an LI, without regard for the resulting
> structure; let us, I say, with open eyes, alter the SGML decl for
> HTML to say SUBDOC YES, which is pretty much the SGML equivalent of
> INCLUDE. If we do that, we can actually parse the doc that will
> result from doing all the includes and see what it looks like.
No argument or elaboration needed from me.
Murray