I agree with your later classification of this as a kludge, and
would much prefer to use either the existing LINK element
or new elements. Note that the HTML spec requires browsers to
ignore elements they do not understand -- that is, to treat
them as though the tags were not there. As this would leave
the contents within the HEAD of a message, it seems reasonable
to interpret this to mean that the contents (which would not
otherwise be allowed in the HEAD part) should be ignored.
This gives you a transition path from trying it out on a small
scale to standardising on it -- without breaking anything on the
way.
> HTTP servers which want to serve documents maintainable by MOMspider would
> need to parse the above MOMtag and send the information as headers in a
> response to any GET or HEAD request for that document.
I would like to draw your attention to the comments in the HTTP spec
about WWW_Link: and the isomorphism between HTTP object header feilds
and HTML head elements. Therer is is suggested that a formal
relationship be made, automatically defining one set in terms of
the other.
The next point is that, although the two specs have the
metainformation in common, they should be kept separate.
This separation should include the MOMspider design.
Remember that GIFs have owners too -- and expiry dates, etc.
Supose we specify this metainformation in HTTP. I think that
it is really useful, and will put it in unless anyone objects.
Owner, that is, as Expires: is already in. You have to leave it
up to a server owner as to how he generates that field.
Nowhere does the HTTP spec say anything about how the feilds
are generated, only what they mean. For example, one could
take the uid or gid fields as a good guide. It is rather system
dependent.
So as a separate issue, we can add the fields for HTML, which
would probably be used by most servers (server admins) to generate
the HTTP headers.
> output is a bit of a kluge. I would prefer to have official HTML
> metainformation elements for OWNER and EXPIRES which would be optionally
> specified within the HEAD element (similar to the TITLE element).
> Similarly, the HTTP response would include that metainformation as
> appropriate headers (note that this has already been suggested for
> the Expires header but I haven't seen any mention of how the expire
> date would be obtained from normal HTML files).
Again, it could be done in bulk, for examle by specifying that
anything in /internet-drafts expires 6 months after its creation
date.
A question: Suppose we have this info duplicated in the HTTP
headers and in HTML. What happens when a client PUTs a document
with conflicting information? Suppose the server stored all the
metainformation in a database. Why ask the server to raed HTML
files all the way through, when for anything else (GIF, sound) etc
the server can just soak up the HTTP headers and treat the HTTP
body as opaque data? Sounds to me as though the client
could be the one responsible for copying the metadata into the
HTML HEAD. The HTTP metatdata (however it is stored) would be
the more fundamental.
> One point which I think may spark discussion is whether we should
> specify the Owner as a LINK relationship rather than as its own
> element. I decided not to do so for reasons of efficiency and
> understandability.
I'll play devil's advocate here.
> If the owner was specified as a LINK, MOMspider
> (and any similar clients) would have to parse through all the fields
> of every LINK header in order to find an owner relationship.
Hey, come on, it has to read all the header lines anyway to
look for OWNER. No more sweat for a machine to look for
LINK REL="OWNS"
> Furthermore, the document author would have to build a contrived
> reverse LINK relationship with fields normally used for document
> references
Not at all -- the LINK element is not normally used for document
references (the A element is usd for that normally). The LINK
elementt was designed to define any two-ended relationship,
or binary predicate. It was designed for relationships like
Jack loves Jill
Jill loves Jack
Jack likes pie
Jill makes pie
Jack eats pie
Jack adicted to pie
Jack needs pie
Jack needs Jill
Jack demands pie
Jill fears Jack
Jack fears "Jack needs Jill"
Jack hates Jill
Check out all the stuff on semantics in hypertext, like
the hairspray (keeps your ideas in places but I can't remember
which brand) from Halasz &co at PARC.
> -- a concept which is counter to understandability and
> everything I know about software engineering.