> > > For instance:
> > >
> > > o REL and REV remain open-ended CDATA strings with the ability
> > > for authors to define their own names.
> >
> > I think that I would lean towards NAMES rather than CDATA,
> > but I am willing to be convinced otherwise. I am thinking
>
> I posted a few reasons why they should be stated in URL form: to allow
> for lookup of a definition over the network, to keep one binding scheme
> for all of the inputs to the behavior of the link, and to be consistent
> with other ways that browsers implement complex link behavior (e.g. mailto)
OK, I am trying to understand how this would work in practice.
So, let's say that we have a REL=linkas:NAVLINKS/NEXT. What
would a browser do to retrieve the meaning of this link type
and how would it procede to interpet it? Are you proposing
that there should be a language to express the appropriate
actions to take? For example, I would expect that a browser
should present or activate an icon in the toolbar to indicate
that the user has a NEXT option and that acting on the icon
-- mouse click -- should act as "GOTO the URL specified by
the HREF attribute".
>
> > that it is reasonable to constrain the name space to this
> > extent, but not so far as to define a restricted set of values.
>
> Everyone seems to want an open ended list of values, there is some dispute
> on how to signal to the author that they are using a 'standard' or non-
> standard value. In the URL scheme this is simple, "linkas:html4/new-type"
> is clearly a new type defined in html4. If REL="new-type" and the author
> has specified that the document is of type HTML4, this can be constructed
> but is less reliable than unambiguously stating the exact behavior desired
> in one place.
Well, a reasonably constrained list of values. I suggest NAMES
so that there can be no upper/lower-case ambiguity. NAMES are
not case-sensitive, CDATA is.
In the case that an author uses a REL value which is not widely
recognized, I still wonder how the meaning and intention of that
value can be conveyed to a user agent. Are you suggesting that
we need a language to express the meaning and intention?
If so, what is that language? How will it be widely deployed?
Do you expect to develop an RFC to describe this language,
or do you expect to target an existing language (such as JAVA)?
>
> > > o The I-D defines a set of reserved keywords from this open-ended
> > > space of names for REL/REV attributes.
> >
> > Yes.
>
> A URL/URI approach does not require new keywords, although the browser would
> have the authority to intercept and interpret certain "linkas:..." types,
> thus making them effectively keywords. The only difference is that this
> allows for some 'keywords' to be in use in scopes smaller than 'all of HTML'.
I see. So there are some knowledge domains for which there exist
link types which are not pertinent to "all of HTML". In the legal
publishing domain, there is "precedent" and "legislation". These
might be used to suggest to a user agent that icons be presented
or activated that would lead to the relevant HREFs. In fact, one
might even expect the browser to present a list targets if there
were more than one link specified with the same REL value.
OK, but now that I clearly see the value of open-ended REL values,
I am still left with lingering doubts about how to express
the meaning and intent of user-defined REL values.
>
> > > o Some reserved words are defined for use with document specific
> > > toobars/menus while others are defined for specific purposes
> >
> > I'd like to read a more complete explanation of these points.
> > Explain the mechanism through which document-specific toolbars/menus
> > will be encoded/generated/taught. What do you mean by "specific purposes"?
>
> Any standard that defines words beyond strict, unambiguous, browser behavior,
> is imposing a specific rhetoric of hypertext. In other words, defining the
> meaning of 'glossary', 'footnote', etc., when these might imply many different
> browser behaviors. Be very aware of crossing this line. Authors will no longer
> control the presentation of their documents if they can't decide for themselves
> when a footnote is to appear as a floating window or collected at the end
> of a section/page. This is the kind of thing that tends to create very heavy
> resistance. Browsers can be trusted to do simple interpretation, for online
> docs or other such documents.
Hmmm! It is not clear to me that the user must have COMPLETE control
over the presentation. Browser development is also an art-form.
If one browser wants to present anchors of type FOOTNOTE as a
pop-up window, another wanted to force a GOTO, and another
wanted to present the content in a pane of the current window,
that's alright by me -- and should be for many information providers.
When someone develops a browser that presents all information and
interface features just as the author intended across multiple
platforms, then I am going to buy shares.
My feeling is that browsers should try to do what they can
to accomodate the needs of the author and reader of HTML pages.
They cannot be required to present information in specific ways
because the browser (user agent) and reader (human) may not be
capable of dealing with what the author specified -- to wit,
non-graphical user agents, seeing-impaired readers, and
HTML to braille or speech synthesis engines.
>
> > > Here is my suggested list for toolbars/menus:
> > > (toolbars can be customised with icons via stylesheets)
> > >
> > > HOME -- defined by browser --
> > > BACK "
> > > FORWARD "
>
> I assume you mean BACK vs. FORWARD is chronological, since it is 'defined
> by the browser'....
I suppose that "chronological" expresses the intent succinctly enough.
So long as we all understand that a more precise definition is
required for the purposes of the I-D.
>
> > > HOTLIST "
> > >
> > > TOP
> > > UP
> > > PREVIOUS
> > > NEXT
>
> ..and PREVIOUS vs. NEXT is spatial. Very much the opposite of the
> dictionary. Sigh. I suppose it is too late for people to relearn 'back'.
No, not spatial. Sequential or hierarchical. The intention with
PREVIOUS, NEXT, TOP and UP is to describe a document tree.
>
> > > TOC
>
> Difference between TOC and TOP ?
They may be the same, but not necesarily. In SCO's online doc,
a link to a book is a link to its table of contents, and is
also the top of the tree. We have considered other options.
For example, the TOP of a document tree could be its title page
or its preface, or ...
If we could have a reasonable expectation that most browsers
had a Table of Contents icon, or had a concurrent view of the
document's Table of Contents, then we would not have to treat
the Table of Contents as the TOP or FIRST page in a document
hierarchy. In fact -- or my opinion -- the Table of Contents
is not actually part of the docment's hierarchy, it is meta-data.
>
> > > INDEX
> > > GLOSSARY
> > > HELP -- for help with orientation, not help on topic --
> > > BOOKMARK -- for author specified menu, caption via TITLE --
>
> These are the rhetorical marks I was scared of. Is there any behavior
> associated with these other than going to a page, or are these just
> names with the standard 'goto' semantics ?
As I described above. For an INDEX, one might expect a concurrent
view of the document's index. Similarly for GLOSSARY. Or, one
might expect that a mouse click over a word or phrase that is
identified with "<A REL=GLOSSARY REV=ENTRY ..." would present
a pop-up window or a balloon with the glossary definition.
We use NAVIGATE for orientation rather than HELP. The semantics
are specified in a cgi-bin script which presents a mini-TOC
which points out where the reader is in the document structure
as well as providing additional informatio about the document
-- such as date of publication, etc, and a link to legal stuff
like copyrights and trademarks.
>
> > > COPYRIGHT
> > > AUTHOR
> > > ABSTRACT
> > > PUBLISHER
> > > DISCLAIMER
> > > URC
>
> Fine, these have nice clear semantics, 'thanks' to our friends the lawyers.
>
> > > The other REL values for LINK
> > >
> > > BANNER -- see HTML3 I-D for explanation --
> > > STYLESHEET
>
> OK.
>
> > > Values for use in defining Guided Tours with <A> element.
> > > These allow Guided Tours to be defined using HTML, for instance
> > > as part of tables of contents, e.g. <A REL=NODE REV=TOC HREF=Chap1.html>...
> > >
> > > NODE -- implies PREVIOUS/NEXT LINKs for given URI --
> > > PATH -- given URI contains <A REL=NODE> links that
> > > should be inserted into the guided tour --
> > >
> > > The browser treats the REL=NODE URIs as forming a sequence of nodes
> > > to follow and sets the <LINK REL=PREVIOUS>, NEXT as appropriate for
> > > each node as it is visited.
>
> Hmm, getting complex. I can see that this is useful but the *browser* SETS
> the REL=?... this is exactly why I suggested that the browser get a URL/URI
> and interpret it as they see fit, rather than having it actually change the
> strings, just change the place where it looks up the meaning of the string.
I don't get your point here.
Murray
>
> --
> 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