Re: Uniform access to descriptions

Ian Davis wrote:
> Xiaoshu,
>
> I think you need to look at section 19.6.2.4 <http://19.6.2.4> of 
> RFC2068 which describes the Link header. This conversation is not 
> about the LINK method.
In that case, I have explained that there is NO need for LINK whatsoever 
(by the principle of orthogonal specification).  What is the point if 
you can describe those relation in "content" but you insist to put it in 
another place.  This rational, in fact, breaks the "uniformness" that 
intend to achieve in *Uniform* Access to Description  (UA2D) because 
there are now at least two places that a client may find the same 
information.  Please explain the rational for that?

HTTP is about deliver *message*.  All HTTP-header's role should serve 
one function - that is how to get message and how to transform the 
*message* in *content*.

Xiaoshu
>
> Ian
>
> On Thu, Apr 10, 2008 at 11:19 PM, Xiaoshu Wang <wangxiao@musc.edu 
> <mailto:wangxiao@musc.edu>> wrote:
>
>
>
>
>     Roy T. Fielding wrote:
>
>         On Apr 8, 2008, at 4:33 PM, Xiaoshu Wang wrote:
>
>             "Honestly, after I read the Nottingham's draft, I dislike
>             it even more.   The LINK header is essentially a "cute"
>             way to move some of the RDF assertions into the HTTP
>             headers. If you exam the proposed Link header more
>             closely, they are more or less the Dublin Core.  What it
>             will lead to is what you described as "transclude" all
>             URIs into the headers.  It is very dangerous and very bad.
>              Consider the copyright LINK. If the content carries a
>             copyright statement, which is different from the LINK's
>             copyright?  Which one is the right one?".
>
>
>         FTR, that is complete nonsense.  Link was defined in 1992.  It
>         is already an
>         HTTP header field.  It's purpose is to define typed links from
>         one resource
>         to another resource, particularly when the representation is
>         not hypertext.
>         It is one of the key components of the Web architecture that
>         was left out of
>         RFC 2616 because the editor was in a rush to move to Draft
>         Standard status,
>         not because we had any intention to remove the field from HTTP.
>
>     Roy,
>
>     I am not proposing that.
>     Here is an excerpt from
>     http://tools.ietf.org/html/draft-nottingham-http-link-header-01.
>     which I believe is what Jonathan referred to new HTTP LINK proposal.
>
>      o  Relation Name: copyright
>      o  Description: Refers to a copyright statement.
>      o  Reference: [W3C.REC-html401-19991224
>     <http://tools.ietf.org/html/draft-nottingham-http-link-header-01#ref-W3C.REC-html401-19991224>]
>
>     I found the 1997's HTTP draft (RFC 2068).
>      http://www.ietf.org/rfc/rfc2068.txt, which section 19.6.1.2
>     <http://19.6.1.2>, describing the LINK.
>
>      The LINK method establishes one or more Link relationships between
>      the existing resource identified by the Request-URI and other
>      existing resources. The difference between LINK and other methods
>      allowing links to be established between resources is that the LINK
>      method does not allow any message-body to be sent in the request and
>      does not directly result in the creation of new resources.
>
>      If the request passes through a cache and the Request-URI identifies
>      a currently cached entity, that entity MUST be removed from the
>      cache.  Responses to this method are not cachable.
>
>      Caches that implement LINK should invalidate cached responses as
>      defined in section 13.10 for PUT.
>
>     I don't what kind of "typed" link should be modeled in LINK, but
>     the requirement for LINK to make sense is that message must be
>     *empty* because there is no other way to tell the reason of
>     *empty* message, such as due to copy right restriction etc..  
>     But the reason for UA2D approach is not based on the assumption of
>     the message is *empty* but *not empty* because by then they can
>     avoid 303 with  LINK+200.  You tell me where is the rational.
>     Xiaoshu
>
>

Received on Friday, 11 April 2008 09:25:46 UTC