Re: Meta info tags

Nick Arnett (narnett@verity.com)
Mon, 19 Sep 1994 08:29:54 -0800

Message-Id: <9409191524.AA10470@nasty.verity.com>
Date: Mon, 19 Sep 1994 08:29:54 -0800
To: murrayb@icis.qut.edu.au (Murray Bent)
From: narnett@verity.com (Nick Arnett)
Subject: Re: Meta info tags

At 3:26 PM 5/12/94 +0000, Murray Bent wrote:

> Where do I find the reference to META tags?

It's in the HTML 2.0 RFC on page 3-2. I had taken a quick look at the RFC
but didn't find it because it's only in the proposed features...

Thanks for the pointer on URCs. The attributes index that our engine
builds looks like it would be easily adaptable for URCs (I'm relieved to
see). I think we've attacked the scalability issues, which are the really
hard ones. I.e., we have equivalents for URNs and URLs within our
attribute indexes, with an open structure for additional meta-data, with
cacheing and scalability.

Now the question. What's the intent for the relationship between URCs and
HTML headers? At first blush, I would think that URCs would contain a
subset of the information contained in the two headers. The "Data Naming"
and "Member Element Control" paragraphs suggest that the intent of URCs is
to contain limited data; if individual publishers wish to provide extended
attributes, I assume that the headers are the only standard place to put
them... But I don't quite see why we wouldn't want to have a small number
of required URC data elements that are always replicated within the Uniform
Resource management system, yet embrace a structure that would allow
publishers to use a compatible format with additional data elements.

For example, in our scheme, the only required elements are our equivalents
of URNs and URLs. Everything else is up to the user.

Well, the place to talk about URCs is not www-talk. In any event, it's
clear to me that if URCs become a standard, the intent is to carry a
minimal number of data elements, so I'm still interested in a rich HTML
header scheme. Besides, customers want us to move a whole lot faster than
the standards bodies. Our main concern is that we head in a direction that
will continue to allow us to incorporate open standards, rather than
heading off in a proprietary direction.

Nick