| > 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.
Agreed, as with several other points.
| > 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?
Your example suggests, though doesn't assert, that the sequential model
would be the ordinary reading sequence. Here's another example:
the book has within it several paths (selections from
the contents), which I want to indicate by BEGIN-->NEXT-->END markup.
Now I know I could use PATH/NODE for this purpose (in which case
perhaps we don't need both PATH/NODE and BEGIN/END). But if I
did mark up paths with BEGIN>END, then the BEGIN wouldn't necessarily
be the TOP of the entire document (the book).
| > 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?
Doesn't, really. The difference is probably in our images of how
they will be used.
| 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?
Sorry, I missed that. Forget about GLOSSENTRY then.
| > 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, ...
Okay, good enough. On reflection, I see that one could use this
feature to locate "the most-cited BIBLIOENTRIES".
| > 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.
Those are rather different; but yes, I can see the point of
a pointer to an author blurb (home page). So this is not "name
of author" but "pointer to info about author." Okay.
| > BANNER. I suspect BANNER could use more empirical discussion, and
...
| > 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.
Yes.
| > 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.
One more word from me, though: the user preferences mechanism
can be a local style sheet override.
| > 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.
I understand that. But while the other values have to do with
semantic description of documents related to the current one
(the one with the LINKs in it), this has to do with the
presentation of the current doc. <A REL=STYLESHEET launching
a special app seems a bit farfetched (and you know that we never talk
about farfetched things here ...). <LINK REL=STYLESHEET is
reasonable; I just yearn to get this stuff out of the document
itself. However, I can see that HEAD is destined to be a sort
of SGML catalog file or poor man's .htmlrc. Okay.
| > The Paths values would seem to be parallel to BEGIN and END.
|
| So, PATH and NODE should move into the Sequence group?
I guess I gave an example in which they're NOT parallel.
Need to wait for Dave.
-- 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