I don't object to reserving the word, even if it has no semantics beyond GOTO.
I believe 'we' is not the html-wg alone. There is already a DTD for 'books'
that includes a definition of 'bibliography' acceptable to the ISO and the APA.
If you havne't consulted this already-standard definition, and overload the
word, you may stomp on the prior art. This relationship has *been* defined and
is in use every time someone sends a tape to a compositor using the APA's DTD.
Not only that, 'bibliography' is a relationship defined in HyperCard and Frame-
Maker, and could easily have a different meaning in PDF or other SGML forms.
Now you want to define it *again*, this time for HTML (only), instead of using
a more general definition already worked out by experts in bibliographies, and
instead of solving the problem for the whole web by defining a WWW link model.
I don't see a good reason to do this. Minimalism is a good reason *not* to.
If you want to standardize 'html3-bibliography' this is less of a problem.
It may even be acceptable to interpret 'bibliography' as 'html3-bibliography'
within an HTML3 document. But if so this has to be stated very clearly, so
when html4 etc. redefine 'bibliography' to ease conversion of SGML documents,
nothing will explode.
There are also many RFCs defining 'standard relationships' between mail
messages, news articles, etc. Some map neatly onto NEXT, PREVIOUS, TABLE_OF_
CONTENTS, some not. Some browsers (notably Netscape) and some converters
(notably HyperMail) already interpret these header values as relationships
and create links. None of them have required any behavior beyond 'goto(HREF)'.
Therefore I reject the claim that any more complex behavior is required.
Terms like 'BACK' already have a meaning within HTML and may be standardized
from practive without reference to any other standard. Let's work on these.
> NEXT, PREV, BIBLIOGRAPHY; yes, we can standardize these values. We need
> have no mechanism built into HTML for extended *those values*.
NEXT, PREV, yes. BIBLIOGRAPHY, no.
> | The legal community, scholarly community, and others will have to support
> | their own characteristic REL values.
>
> NEXT, PREV, BIBLIOGRAPHY are all relevant to scholarly work and, I suspect,
> law, too.
Yes, and they have *their own meanings* there. NEXT/PREV, e.g., might be
sequences of cases/interpretations that succeed each other over time, OR
they might be cases viewed in the order of their relevance to the current
matter under investigation, etc. A BIBLIOGRAPHY might have the scope of
the current case only, the basic principles of this area of law, the key
opinions that form those principles, in fact every document might have 3.
In scholarly work we have simple bibliographies, annotated bibliographies,
historical bibliographies and exhaustive bibliographies. Not all would be
presented the same way. An annotated bibliography is more of a hypertext,
the others are more like listings, the more complex are actually databases.
Again, you want to reserve the words, no problem. You want to define their
semantics, or let *browsers* define their semantics (not just presentation),
it's worrisome.
> | those values supported. In some cases those values have hundreds of years of
> | tradition and documentation behind them.
>
> These are mostly the values Murray is working on.
Exactly the issue. We are reaching far beyond the html-wg's expertise here.
We do *not* have to define the semantics of these REL values, and *should* not.
We can leave this up to the authors by simply standardizing our own practice,
and encouraging others to do the same.
> For general use we can define a short list that gets us somewhere. If
> browser developers want to support others, they'll introduce them.
It is not browser developers but *authors* that must be free to introduce
values that are meaningful to their readers and each other.
> Nor I. It's not motivation that's at issue here, it's the specification
> of semantics for common literary forms.
Absolutely. You seem to believe that we can and should specify such semantics
as a short list within HTML, without reference to external usage or prior art.
I do not believe that we should attempt to do anything more than reserving the
key words and saying 'you can't implement these in such a way that a document
that is expecting 'goto (the given HREF)' will bomb'.
I believe that the entire history of hypertext systems shows the folly of
complex link models or link semantics interpreted by the browser. Systems
like HyTime or Xanadu, which imposed a strong relational model, were *not*
widely adopted. Systems like HyperCard and HTML, which do not, *were*.
Altering the *presentation* is fine, but the standard doesn't care about
presentation. Altering the semantics of navigation should be done at the
WWW level, not the HTML level.
The WWW *has* an abstract link model that is universally implemented:
" Go to (the given HREF) and present what is there - process that document
and any links *from* that document according to *that document's format.*"
I don't see any guarantee there, that a PATH/NODE defined in HTML applies,
or that you show a GLOSSARY entry without going to the GLOSSARY page itself,
etc. I am opposed to anything that extends the WWW link model implicitly.
For one thing, the above is respected in PDF, RTF, SGML, HTML, VRML, etc.
Any 'improvement' defined strictly within HTML will not be. HTML-specific link
behavior is about equivalent, in my mind, to HTML extensions that don't fit in
SGML. All they do is increase the burden of 'exceptions' on the developers,
increase the credibility of 'alternatives' to HTML with even more features,
and guarantee that a UA designed to expect the simple 'goto' will not work.
Imagine a CCI program that is trying to deal with navigational exceptions:
"If this is an A tag, go to its HREF and process that document like this
one. If this is a LINK tag, and has no REL value, treat it like an A.
If this is a LINK tag, and has the REL value 'glossary', follow it,
process the glossary item, and check if the link left us on the same
page. If not, go back. If so, assume the browser has implemented some
'special' behavior for glossaries and note this in a flag. If this is
a LINK tag, and has the REL value 'bibliography', and this browser has
implemented 'special' behavior for glossaries, check if it implements
any 'special' behavior for bibliographies that screw up our navigation...
...If this document is a PDF, find the first LINK, assume REL is 'goto'
unless it is an INCLUDELINK, in which case..."
What a nightmare. Well, at least it will keep bad hackers employed forever.
> Huh? You're telling us that we can't standardize a short list of REL
> values.
I'd be happy if we standardized a short list that dealt strictly with
navigation, that we could safely implement by calling browser internal
functions, and which had no navigational implications beyond 'goto (HREF)'.
I have even proposed solutions like the 'anchor text convention' to bend
over backwards to ensure that browser innovation can be supported in a
backwards compatible way.
>You're telling Murray he can have no recourse to this group
> in pursuit of that end.
I'm telling this group that there is no *need* to standardize values
that can safely be implemented as 'goto (the given HREF)', because a
browser can always default to the 'goto' behavior for words it does not
recognize. If we want to reserve words and say that these *must* be
defaultable to 'goto (the given HREF)' then we at least prevent future
alteration of documents.
>I disagree entirely. REL is useless without
> a common set of values that can be implemented by all browsers.
Once we get beyond simple navigation, the values are far less common,
and indeed become application-specific. Even the semantics of generic
terms are application-specific.
Have you ever seen a HyperCard stack ? One of the main activities of
HyperCard authors was inventing new link transitions. The only standard
'REL values' in HyperCard were, as I recall: HOME, NEXT, PREVIOUS. All
three were just 'gotos', no matter how fancy the transitions could get.
HTML has only one standard 'REL value' now, the 'GOTO'. HOME, NEXT,
PREVIOUS, now seem to be universally implemented amongst browsers.
The HyperCard experience would suggest that further standardization
is not necessary. Experience in other hypertext systems (Notecards,
KMS) suggests that author-selected link relationships work better than
developer-selected. The lack of a WWW-wide link behavior model would
suggest that further standardization is making dangerous assumptions.
> Establishing that set is a proper function of this group. Arguments
> in favor of doing that are not "lobbying."
You seem to have a negative reaction to this word. Fine. Allow me to
rephrase:
SCO and other authors of online documentation can and should work together
to establish a very rich set of REL values for use for specific applications
(e.g. Unix man pages). The work SCO has already done should be preserved
and supported. Nothing in the HTML standard should contradict it without a
solid reason. However, not all of this work necessarily applies to all
HTML or Web authors, who may often need to impose their own relationships,
and in any case need application-specific values to generate web mappings.
Values need not be written into a standard (or even RFC) to be useful, if
authors can be sure that the values that they choose will not be interpreted
by other' UAs in an incompatible fashion. It does not appear as if there
is any navigational behavior support required beyond 'goto (HREF)'. It seems
to me that a guarantee that SCO's list of values will not be interpreted by
any UA in a way that leaves you in a different place than 'goto (HREF)' is
all that is required. But we might just as easily demand this of all REL
values, regardless of origin, in which case no special standardization of
such values is required.
I reject absolutely your claim that 'browsers must agree' how to interpret
a specific REL value. It is users that must agree on what it means, and
they're more flexible. If broswers agree to interpret *every* REL value
as affecting *only presentation*, and never navigation (i.e. they will
always leave you on the same page as they would have with no REL value),
we're within the scope of the html-wg, and need only standardize such an
agreement. If we wish to move beyond the minimum, then we may standardize
already-universal relationships that formalize existing navigational rules,
including the HOME, NEXT, PREVIOUS, and those from the news and mailing
list RFCs (using the precedents of Netscape and HyperMail as guidelines).
"Do not affect navigation" = "may be safely interpreted as 'goto (HREF)' "
> | My point exactly. Many communities will be building on this mechanism.
> | Not all of these communities have been tested by SCO's implementation,
> | which seems to focus on problems of navigation and online documentation
> | of documents with a traditional structure. Other issues are less clear.
>
> Problems that will always be with us. We're not dealing here with your
> unclear "other issues." Nothing Murray has proposed prevents anyone
If you're not dealing with these issues (cross-format navigation, universal
navigational paradigm for the entire WWW, name space conflict with existing
usage in other SGML DTDs, guaranteeing backwards compatibility for browsers
which only implement 'goto (HREF)', unifying the various means of calling
external behavior from UAs under a common overloaded attribute) then don't
presume to minimize them. I think it is clear that you do not understand.
Don't compound the problem by insisting that you understand the implications.
> else from supporting other values for REL. The appeal to "communities"
> is bogus. It's the HTML user community that needs standard REL values.
Each such community needs their own. Each such community can set their own,
if we are willing to back off from over-zealously setting up a complex list.
> | So let's err on the side of conservatism, and give others room to test
> | their own REL values, and let practice lead the standard there too.
>
> REL values can't be deployed unless they're agreed upon. Murray was
Wrong. Users understand REL values fine in context, even if they are heavily
overloaded or incompatible with other uses (people are fairly smart you know).
There is a lot of research into typed-links in hypertext, I'll post if you like.
All of it says that authors should define links in context of the document.
It is the browsers, or other UAs, that get confused and misinterpret things.
For these we need a very short, very minimal, list of things they *might* do,
that will not cause problems for browsers that don't recognize those values.
Arbitrary values are fine as long as the browser doesn't attempt to get too
fancy with them, screw up or fail on things it doesn't recognize, or leave
you somewhere you didn't expect to go. That's the only 'standardization' we
really need.
> able to do that in one closed system; what we need to do here is agree
I'm not sure that SCO and all it's users are all that 'closed' a system.
You only need universal values for things that go beyond presentation,
and in that case you need to agree not just with 'the HTML user community'
but the whole World Wide Web, as I and others have stated several times.
> upon a small set of common values that browser developers in general
> can implement. "Testing" and "practice" simply won't get us there.
I disagree. SCO was able to 'test and practice' their way into something
useful.
> And are not needed for NEXT, PREV, BIBLIOGRAPHY, ...
Not for NEXT or PREV. For BIBLIOGRAPHY, I think so.
-- 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