Re: Uniform access to descriptions

Xiaoshu Wang wrote:
>>
>>
>> I have not seen you give an argument about how the use of a "Link"
>> breaks *anything* much less HTTP. In fact, Link was part of an earlier
>> HTTP RFC 2068, and was apparently left out as an editorial oversight.
>>   
> There are a few issues here.  Of course, adding things don't break
> things.  It never does.  But it steers you away from standardization. 
> What we would eventually want people to do is to just take one of the
> few methods and get what they want.  Not by infinitely extending a
> protocol.  Hence, proposing LINK, in fact, contradict what the title
> of this discussion does - which is the "Uniform access".  I guarantee
> you if we grant this exception, there will be other similar request
> for making LINK2, LINK3, etc.
Actually, having Link headers with an URI extensible link relation makes
any request for "Link 2" or "Link 3" moot, since one can just use a Link
header. Also, you seem to be ignoring the fact that adding something
back that was accidentally deprecated and is actually supported by
existing software is a bad thing. Look, by your argument of "never
extend the protocol" we'd still all be on ARPANet. The idea is to make
the protocol cover the use-cases and not break and follow trends in
existing deployments.
> I have argued earlier, if people know what kind of LINK they want, it
> means they also know what kind of content type they want.  Using
> content negotiation is cheaper because it takes one round trip but not
> two.
By that argument we should have links "transclude" all links
automatically, because then people don't have to bother with following
hrefs. Look, of course a link is going to take another request, that's
why it's called a link to *another resource* not the same resource.
> Second, the semantics of LINK is in fact incorrect.  I dislike the
> general use of the word metadata.  HTTP headers are the "metadata"
> about the message payload - NOT the "metadata" of resource.  (Of
> course, this leads to my different viewpoint of what a URI
> identifies.)  Hence, whatever is in the LINK should be, as all other
> HTTP headers, about how to parse the payload and nothing-else. Using
> HTTP LINK for the metadata of the resource that the URI identifies, in
> fact, breaks the web's founding principle that tis the orthogonality
> of protocol.  Which makes the HTTP LINK an even worse offense.
Well, obviously the Web should work based on your likes and dislikes :)
However, HTTP headers do things other than parse the payload, ala
Location (which like Link can take a URI) and Age.
>
>> Here is the use-case as attached below. Note that we do not specify URIs
>> for the XML documents, therefore rending the argument to "just use
>> conneg" void
>>
>> >From GRDDL Use-Case document (I think Ian Davis wrote this part..):
>>
>> "Oceanic is part of a consortium of airlines that have a group
>> arrangement for the shared supply and use of aircraft spares. The
>> availability and nature of parts at any location are described by
>> AirPartML, an internationally-agreed XML dialect constrained by a series
>> of detailed XML Schema. Each member of the consortium publishes the
>> availability of their spares on the web using AirPartML. These
>> descriptions can subsequently be searched and retrieved by other
>> consortium members when seeking parts for maintenance. The protocol for
>> use of the descriptions requires invalid documents to be rejected.
>> Oceanic wishes to also publish RDF descriptions of their parts and would
>> prefer to reuse the AirPartML documents which are produced by systems
>> that have undergone exhaustive testing for correctness. There is no
>> provision in the existing schemas for extension elements and changing
>> the schemas to accommodate RDF would require an extended international
>> standardisation effort, likely to take many years. This means they
>> cannot alter their XML documents to use GRDDL. Using the ability of HTTP
>> Header Linking Draft to specify Link and Profiles for GRDDL
>> transformation in HTTP Headers, Oceanic Consortium can serve RDF via
>> GRDDL without altering their XML documents. "
>>   
> Do you think that is a valid use case for a healthy argument?
Ask Ian Davis, but that's how a lot of XML documents (spec) are in the
wild. And again, you can't use conneg to automate a GRDDL transform. I
suggest you read the GRDDL spec.
> Your opinion is already decided by making XML spec non-modifiable and
> by pre-determining "using the ability of HTTP Header Linking
> *draft*".  Wouldn't it be better to say: "using the *existing* ability
> of HTTP content negotiation ..."? Which way is better? Using currently
> spec or extending it for something that it can already do?
How about using the spec as it was written in RFC 2068 [1]. Perhaps you
should actually take a look at that before throwing around accusations
that thinks are being "added" for no good reason. Obviously the editors
of RFC 2068 thought it was a good idea, and they seem to want it back,
as does it seem the IETF HTTP WG. The only people against this seem to
be, rather oddly, SemWeb heads who have their own favorite way of
providing metadata. Which is fine, but why not allow people more options?

So, Mark Nottingham is not adding anything new (again, perhaps you
should actually read his IETF draft[2]), and I am just showing that this
can help solve httpDescriptions-58.  The only thing we could be accused
for  adding anything new, with the exception of adding URIs to link
relations in order to prevent the need for "Link 1", "Link 2".
> Content negotiation, in fact, don't need you to use RDF or etc.  If
> their community are bound to do something uniformly, they can design
> their own mime-type to do any profile etc.
While I appreciate the time you are putting into the commentary,  this
is about as productive as the "What is Resource?" argument.
> Xiaoshu
[1] http://www.faqs.org/rfcs/rfc2068.html
[2] http://tools.ietf.org/html/draft-nottingham-http-link-header-01

-- 
		-harry

Harry Halpin,  University of Edinburgh 
http://www.ibiblio.org/hhalpin 6B522426

Received on Tuesday, 25 March 2008 00:17:39 UTC