Draft spec for Link Types
Chris Hoess
types to
<URL:http://bugzilla.mozilla.org/showattachment.cgi?attach_id=52849>.
While this is somewhat tangential to the actual implementation of the
Site Navigation Bar ("link toolbar"), the number and identity of buttons
will probably depend on which keywords are equated in this document.
Comments are also welcomed on the specification in general. (I know
there's already a thread on n.p.m.ui for the toolbar implementation, for
those interested in discussing it.) To reduce spam, please keep your
comments on the newsgroups and not in the bug (whose number I've cleverly
omitted).
--
Chris Hoess
Link Toolbar Guy
Gervase Markham
> I have just attached a draft specification covering the semantics of link
> types to
> <URL:http://bugzilla.mozilla.org/showattachment.cgi?attach_id=52849>.
This document, as plain text, is very difficult reading. Any chance of a
marked-up version?
Gerv
Chris Hoess
At some point, I guess. Plain-text 72-char-wrap *is* the standard RFC
format.
--
Chris Hoess, tired
Gervase Markham
> format.
RFCs have indenting, numbering and far more whitespace. See, for
example, http://www.ietf.org/rfc/rfc2396.txt . If you are trying to
emulate an RFC, emulate one. :-)
Gerv
fantasai
>
> I have just attached a draft specification covering the semantics of link
> types to
> <URL:http://bugzilla.mozilla.org/showattachment.cgi?attach_id=52849>.
>
| 2 Link Types (rel and rev attribute values)
What is the context for this document? Part II of what?
| This section includes a list of possible link types.
^^^^^^^^
predefined?
| Link types are defined by the HTML 4.01 specification as SGML CDATA;
^^^^^^^^^^^^^
DTD
| This document attempts to define the semantics of individual link
| types; it does not attempt to describe all possible changes in
| semantics that can occur when link types are combined.
Do semantics change on combination? I've heard it both ways, though
I think that having the list items independent makes more sense. It
is, after all, a list of link types that just happens to be space
(rather than comma) separated.
| Generic terminology is used in the descriptions below, to describe the
| use of link types in both "rel" and "rev" attributes. In a "rel"
| attribute, the target of the link (indicated by the "href" attribute)
| is the first resource, and the anchor is the second resource. In the
| "rev" attribute, it is the anchor that is the first resource, and the
| target that is the second resource.
This is confusing.
- You may want to use "source" and "destination", or something
similar. Names are easier for humans to handle than numbers,
since they are associated with a concept. (You only need to
define the types for rel values; rev can be found by switching
the two terms.)
- Define rel and rev explicitly instead of impying the difference with
"generic terminology".
| child: this link type indicates that the first resource is
Take out "this link type". It's redundant, and it doesn't add anything;
I already know it's a link type--it says so in the section heading.
| /ancestor/
| /descendant/
What are these here for? Does /x/ indicate a placeholder of some
sort?
| the root of the hierarchy which contains the second resource.
^^^^
I think the word "top" is most often used with hierarchies.
| sibling: this link type indicates that the first resource and the
| second resource share a hierarchical parent; that is, they are at the
| same level in the hierarchy. ^^^^^^^^ =
Take out the "that is". It suggests that two resources are siblings
if they are at the same level--which isn't true, since they could be
'cousins' and still be at the same level. The sentence is extra
information, not a restatement of the definition.
| These link types are similar in function to the hierarchical link
| types, but are used to describe an ordered sequence of documents (a
| special type of hierarchy).
|
| begin or first: this link type indicates that the first resource is at
| the beginning of the sequence which includes the second resource.
| It may be considered a special case of the origin or top link types.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| next: this link type indicates that the first resource immediately
| follows the second resource. It may be considered a special case of the
| child link type. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^
(and also for parent)
A tree can be simplified into a linked list, but
I don't think a sequence is a special type of
hierarchy: A hierarchy encodes levels into its
organization, where one is greater than the other,
while a sequence encodes order, where all are
pretty much regarded as equal.
Applying this to documents -
Suppose I have a book with three chapters and a
table of contents:
TOC, Ch1, Ch2, Ch3
It can be organized into a sequence of ToC -> Ch1 -> Ch2 -> Ch3,
which is the order it normally falls into when serialized.
But this doesn't mean that Ch1 is the parent of Ch2!
Ch1 is, however, the /sibling/ of Ch2. One could
argue that the Table of Contents is the parent of
all three chapters: It is one level of abstraction
higher than the chapter content.
We can combine the sequence and the hierarchy thus:
TOC
|/_ | \
Ch1->Ch2->Ch3
So, a list of link relations from Ch1 to ToC could be "first next parent".
Ch2 could link to Ch1 as "previous",
to Ch3 as "next",
and to ToC as "first parent".
As you see, 'next' does not necessarily mean 'child'.
| parent:
up?
| start: this link type is defined above in section 2b.
Just say "see 'start' under section 2c". It's less passive and more
lively. (Relatively speaking. I know "See x" is generally not considered
very exciting. :)
| 2d Informational Link Types
I'd suggest splitting this into two sections -
one for linking to document parts,
and another for linking to information /about/ the document.
It's easier to digest that way.
Something like this:
Document Meta
------------------------------------------------------
appendix author
biblioentry copyright
bibiography disclaimer
bookmark editor
chapter made
citation publisher
content or toc trademark
definition
find or search
footnote
glossary
help
index
section
subsection
translation /* not too sure about this one */
| bibliography: this link type indicates that the first resource _ia_
| a bibliography to the second resource or the collection of resources
^^
is a bibliography for
| content or toc: this link type indicates that the first resource is a
^^^^^^^
contents or toc
| copyright: this link type indicates that the first resource contains a
| copyright notice applicable to the second resource. It is not intended
| to exclude other means of announcing copyright. ^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Take this sentence out. It's not needed any more than "It is not intended
to exclude other means of announcing authorship" is needed for 'author'.
The copyright notice being linked to may be at the bottom of the source
page; I assume this is what you did not want to discourage?
Likewise for 'disclaimer' and 'trademark'.
| find or search:
Where'd 'find' come from?
| glossary to the second resource, or the collection of resources
^^ ^
for (no comma here)
| index: this link type indicates that the first resource is an index for
| the second resource, or the collection of resources including the
^
(no comma here)
| 2e The "alternate" Keyword
^^^^^^^
Link Type (no?)
| the link type "stylesheet", which are beyond the scope of this
^^^^^^^^^^
"stylesheet", discussion of which is beyond the scope
| meta: this link type indicates that the first resource contains meta-
| information about the second resource. This is often, but need not be,
| an RDF file. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Use "for example"; it doesn't make RDF sound like the generally accepted
standard for meta-information. (It's more impartial.)
| stylesheet: this link type is used to indicate that the first resource
| is a stylesheet to be applied by the user agent to the second resource
^^^^^
stylesheet that may be applied
| in some or all circumstances
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Take this out.
| shortcut icon: these two link types, when used in conjunction, are used
Please, no. One token. Put shortcut-icon or just plain 'icon', but I
do /not/ want to encourage "shortcut icon". It's not a shortcut.
| by some user agents to display the first resource (usually a small
| image) in conjunction with user-agent provided mechanisms of accessing
| the second resource.
What's considered an "icon", and how is it related to the page? Tell me that,
not how to display it.
fantasai
>
> So, a list of link relations from Ch1 to ToC could be "first next parent".
That should read "first prev parent".