There are two things I'd like to bring up in this discussion.
1) When I first saw the <LINK> tag, I was very excited and sad to see no one
had pursued implementing it. Hypertext links aren't the only way that one
document should be connected to another - documents can have higher-level
relationships to other documents, as shown below. I also realized this was a
very elegant way to implement group and public annotations:
1) I download an html document
2) I either edit it, or quote from it in a response
3) my file is saved and placed in a public space on my machine
4) the remote server is notified of my revision/followup
5) the next time the remote server dishes out the original file, it
inserts a <LINK> tag right after <HEAD> that might look like:
<LINK REL="annotation" HREF="http://mymachine/myannotation.html">
Well, maybe it doesn't seem elegant to you, but it does to me :)
I have a few more thoughts in this direction if people are interested.
2) There are some other higher-level bits of information I'd like to keep
about HTML files on my system, and actually files of *any* data type -
information like "Creator", "Last Revision Date" (which could be much
different than Last Modified!) "Production Stage" (editing? art? copy
checking? published?), etc. Now, we *could* try and solve this problem
in HTML - define those REL tags to include the above and build
publishing tools and servers that use them. However, the problems we'd
be solving here would still exist for non-HTML files. Sure, plain text
files could have headers, PDF files must have some sort of
meta-information scheme, and hell even GIF's can have comments put in.
But it would be really painful to reinvent the wheel for all these data
types.
To me it seems like the solution being screamed for is a parallel
meta-information file that sits next to any given file which contains
this higher-level information. This is definitely not a new idea - this
is the strong point of the Mac file system's data and resource fork
setup. This is also echoed in systems like RCS/SCCS. Before people
scream that it would make their HTML infospaces harder to manage, I'd
Unix tools could be written to manage these parallel files pretty easily,
like cp and rm and mv. It also means HTML wouldn't have to try and solve
all the problems of existing in the infospace on its own, making the
files a lot more portable to other areas. Information in these
meta-files would be what gets thrown into HTTP headers - "WWW-Link"
instead of <LINK> for annotations for example. It's also nice to think
of a situation where the meta-information could be highly dynamic (like I
mentioned above in adding annotations) and the data file itself
considered much less dynamic.
So, what I'm really saying here is, it's very tempting to suggest that
we address the need for meta-information in HTML itself, but given that
this is a more general problem that needs to be solved for all data
types, then maybe a more general solution is needed. My only contrary
thought is this - maybe if we view HTML files as being a "wrapper"
around other objects of other data types (which would seem to be in line
with the motivations behind the WWW project from the beginning) then
maybe we *can* solve the problem in HTML, and in effect have HTML become
the meta-information-file for other data types by always having data be
inlined into HTML. This would of course require browsers to do something
intelligent with something like <IMG SRC="foo.mpg">, but that's something
some browsers handle already. This seems like a pretty clunky solution
though...
Anyways, this is all food for thought.
Brian
On Wed, 16 Nov 1994, Murray Maloney wrote:
> I think that even if the basic list of keywords were provided
> -- establishing current practice in 1994 -- then I would be
> more inclined to accept a pointer to an informative appendix
> or to a WWW site. However, I may add that URLs are fragile
> and I would certainly prefer to see an informative appendix.
>
> As to the specific values which are documented at the CERN URL:
>
> http://info.cern.ch/hypertext/WWW/MarkUp/Relationships.html
>
> I have to say that I am a bit confused by the relationships
> as described and I would certainly benefit from more detailed
> descriptions, with concrete examples and descriptions of how
> a sample application might deal with a <LINK> or <A> tag
> with REL and/or REV attributes set with these keywords.
>
> I also note that that there seem to be very few relationship
> keywords that can be used to describe hierarchical relationships
> (Precedes, Subdocument, and possibly Embed and Present),
> and also very few that can be used to describe a relationship
> to common parts of document structures (Table of Contents, Copyrights, etc.)
>
> UseIndex
> UseGlossary
> Annotation
> Reply
> Embed
> Precedes
> Subdocument
> Present
> Search
> Supersedes
> History
> Made
> Owns
> Approves
> Supports
> Refutes
> Includes
> Interested
>
> Dan, I think, posted a list a few days ago that included many
> keywords that are not present of the list that Tim maintains.
>
> Keywords that are currently being used in the SCO help browser
> include:
>
> Previous - points to previous node in linear document
> Next - points to next node in linear document
> Contents - points to a table of contents related to this node
> Index - points to a standard index related to this node
> Navigate - points to a navigation node related to this node
>
> Others that we'd like to use in the future include:
>
> Library - pointer to aggregation of document sets
> Set - pointer to aggregation of documents
> Document - pointer to top-level ancestor in document heirarchy
> Chapter - pointer to chapter-level node
> Section - pointer to section-level node
> Parent - pointer to parent in document heirarchy
> Sibling - pointers to siblings in document heirarchy
> Child - pointer to children in document heirarchy
>
> I'm looking for a very well-defined and specific set of relationships.
> These are some that come off the top of my head, but I am sure
> that I will think of others. Our experience in developing a help sstem
> with an adapted version of Mosaic has shown us that the power of
> WWW-capable browsers is increased significantly through the use
> of the REL and REV attributes.
>
> Please, let's broaden this discussion.
> I think that we could have a lot to gain.
>
> Murray
>
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Your slick hype/tripe/wipedisk/zipped/zippy/whine/online/sign.on.the.ish/oil
pill/roadkill/grease.slick/neat.trick is great for what it is. -- Wired Fan #3
brian@hotwired.com brian@hyperreal.com http://www.hotwired.com/Staff/brian/