# Re: Meta info tags

Michael Mealling (Michael.Mealling@oit.gatech.edu)
Tue, 20 Sep 1994 12:15:00 -0400 (EDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Norbert Leser - OSF DCE:: "Re: Last Call: URL to Proposed and URN- and IRL-Reqs to Informational"
- Previous message: Michael Mealling: "Re: Meta info tags"
- In reply to: Nick Arnett: "Re: Meta info tags"

    From: Michael.Mealling@oit.gatech.edu (Michael Mealling)

    Message-Id: <199409201615.MAA23002@oit.gatech.edu>

    Subject: Re: Meta info tags

    To: narnett@verity.com (Nick Arnett)

    Date: Tue, 20 Sep 1994 12:15:00 -0400 (EDT)

    In-Reply-To: <9409191524.AA10470@nasty.verity.com> from "Nick Arnett" at Sep 19, 94 08:29:54 am

Nick Arnett said this:
> At 3:26 PM 5/12/94 +0000, Murray Bent wrote:
>
> 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.

URCs can <b>contain</b> a subset <b>of</b> the HTML headers but they are not
limited to that subset.

> 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...

Not really. Those two paragraphs only specify that we need some method of
specifying 'well known' attribute names. It is intended that anyone can
put any attribute/value pair they want in a URC. There are no gaurantees
that anyone will be able to use it but if it is a well known pair then
atleast someone can find a definition for it.

> 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.

Essentially correct. We don't require URNs in a URC because some services
won't have them or won't need them. We don't require a URL in a URC since
we allow resources to 'expire' off the net. Since you can have instances
where niether are there we don't <b>require</b> anything in a URC.

> 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.

URCs are not meant to carry a minimal number. My best hope is that they
carry a very rich amount of information that allows ALL systems (not
just those that understand HTML) to parse them easily depending on how
much information they require to function.

-MM

    --
    ------------------------------------------------------------------------------
    <HR><A HREF="http://www.gatech.edu/michael.html">
    <ADDRESS>Michael Mealling</ADDRESS>
    <ADDRESS>michael.mealling@oit.gatech.edu</ADDRESS></A>

- Next message: Norbert Leser - OSF DCE:: "Re: Last Call: URL to Proposed and URN- and IRL-Reqs to Informational"
- Previous message: Michael Mealling: "Re: Meta info tags"
- In reply to: Nick Arnett: "Re: Meta info tags"