I agree in principle and in general with Murray's proposal. I believe
it to be well within the scope of this WG. I like being able to have
both REL and REV relationships (and to aggregates, which could be done
without cgi indirection by appropriate HTML indirection). I think
Murray has adequately answered Roy's objections to this thread.
Furthermore, this is real important stuff. A coordinated use of
these REL and REV values is a way to publish compound but
well defined documents without developing the element structure of HTML.
It's a way of overcoming the radical atomism of HTML.
First some stuff on Murray's proposal:
1. A usability nit: instead of CONTENTS, let's call it TOC. CONTENTS is
ambiguous, as GLOSSARY, for example, is not (am I the TOC or the contents
referred to by the TOC?).
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.
3. NAVIGATE seems suspiciously like "other." Are you actually using
it, Murray?
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?
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.
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.
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?
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?).
========================================================================
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.
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).
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.
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.
==========================================================================
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.
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 Paths values would seem to be parallel to BEGIN and END.
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.
Regards,
-- Terry Allen (terry@ora.com) O'Reilly & Associates, Inc. Editor, Digital Media Group 101 Morris St. Sebastopol, Calif., 95472 occasional column at: http://gnn.com/meta/imedia/webworks/allen/A Davenport Group sponsor. For information on the Davenport Group see ftp://ftp.ora.com/pub/davenport/README.html or http://www.ora.com/davenport/README.html