I wouldn't call this 'usability' quite but as DocBook already uses TOC,
and it *is* less ambiguous, I'd tend to agree. Does the (formerly) APA DTD
use it as well?
> Anyway, I'll think about this some more, and I suspect that others
> will try to convince me to bend to popular opinion.
I'd like us to adopt the principle that if the APA and DocBook assigned the
same semantics to the same term, we can consider it a 'de facto standard'
and simply adopt the term into HTML. Analogous to what I proposed earlier
for NNTP 'pointers' etc.
> > 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.
I tend to agree, although I think a bookmark can also be more of a navigation
aid, i.e. part of a PATH, similar semantics in many cases to a NODE. I
would rather have document authors thinking of bookmarks as NODES of a
corpus on a particular topic, than as 'special marks'. This seems like a
UA concern in any case.
In my experience URLs are assigned 'value' as bookmarks, are organized into
hierarchies, then into fully annotated pages. I.e. the process tends to be:
URL as destination ->
URL as bookmark ->
URL as part of a hierarchy (on a 'page' or 'menu' of links) ->
URL embedded in an authored document (if the user cares enough to author it).
I for one wish UA's would support this process much more explicitly. I do
not want us to do anything to confuse UAs that try to do so.
> e.g. describing the wider context and offering
> further links to relevant documents. This is
> aimed at reorienting users who have lost their way.
Like the Sun OpenWindows 'SPOT HELP' ? Died when they moved to Motif.
Sigh.
> 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?
Hierarchies ("trees"), sequences ("paths"), and probably also bookmarks,
seem best supported by a general mechanism to build directed graphs of URLs.
Even if the 'graph' is a strict list or tree 95% of the time, we'll regret
not having this flexibility later. I favor generalizing PATH/NODE over
reserving special terms for trees or sequences, but that may be less usable.
Overly-abstract models are hard for many authors to comprehend, the idea of
'author' as 'authority' over the document is never going to go away, and most
documents will continue to have a linear path with a TOC as its 'backbone'.
Note that for some documents (i.e. reference docs) BEGIN would be the TOC,
but for others (i.e. novels) BEGIN would be the first page of section 1.
With a known 'bookmark' (in the traditional sense) it would be the marked
page. With other information (i.e. a user question) it might be different
(e.g. the answer in the FAQ that answers that question). Context is
everything. Is a context-free 'BEGIN' useful ?
> > 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".
Agreed. Semantically-meaningful document types are most likely application
specific.
> > 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.
'traditional documents' have a TOC, BIBLIOGRAPHY, GLOSSARY, INDEX, etc.,
and the assignment of these names to these elements is a 'navigational aid'
sufficient for most navigation within such documents. On the other hand,
BIBLIOENTRY and FOOTNOTE seem to have implications for navigation, which
worry me... as would GLOSSENTRY...
> And anyway, what difference does it make?
These all worry me as they do not seem to gracefully degrade to the
'goto (HREF)'. I can see UAs implementing them as 'special' popup windows
etc. A Footnote is not much good unless you can avoid writing a whole
HTML document, header and all, to represent it. Thus I suspect that the
HREF may end up not representing a complete document. Also I don't want
to be guessing, in my CCI programs, what the heck I just did to the
user by following a FOOTNOTE, GLOSSENTRY, or BIBLIOENTRY link... can we
clarify the implications of these ?
> 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?
Both or neither. As far as the wording is concerned, follow DocBook/APA.
If it's ambiguous in those DTDs, then they should be changing theirs too.
> > 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
They *act* the same but they do not *mean* the same thing, quite.
A CITATION will be a BIBLIOENTRY but not all BIBLIOENTRIES will be
CITATIONs.
> that searching software might want to locate anchors which
> identified themselves as a CITATION. This may not be needed,
Yes, I agree, distinguish CITATION from other forms of linking. It has
a very clear semantics in scholarly work. However it should be defined
to have the same meaning as in a citation index, i.e. you are considered
to be quoting prior art or seminal work in the relevant field of study.
> 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."
It's semantics are very broadly accepted by existing software (i.e.
citation index systems). That is reason enough to leave it in. We
should be trying to find more with such clear semantics rather than
trying to 'fill out' the list (effectively inventing a semantic model).
> > 8. Meta Documents. I understand that you might want some of this
> > stuff in linkable boilerplate. (I wonder whether a link to a
Linkable boilerplate is getting universal these days (long lists of
copyright notices applicable to the web site, etc.). I for one just
wish I had an HTML #include....!
> > 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.
> Oh -- I also want to continue to use the five keywords that
> SCO has already deployed.
> > 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.
I'd argue to fold Hierarchy and Sequence into Navigational, leaving us
with Browser-defined and Navigational. Why do we impose hierarchy and
sequence except to aid navigation ?
As you say:
> > The Paths values would seem to be parallel to BEGIN and END.
>
> So, PATH and NODE should move into the Sequence group?
No, unify them all under 'navigation'. If you like you can subclass
navigational aids as specific to styles (e.g. scholarly, traditional
document, etc.), leading us towards: nav-scholarly-citation and
traditional-bibliography... no mistaking the semantics of these!
> > 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
Yes this worries me *very much*. INCLUDE needs to be thought out.
> > 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.
Me neither. I think it's obvious that this is a big scary thing.
-- Craig Hubley Business that runs on knowledge Craig Hubley & Associates needs software that runs on the net mailto:craig@hubley.com 416-778-6136 416-778-1965 FAX Seventy Eaton Avenue, Toronto, Ontario, Canada M4J 2Z5