Re: New Version Notification for draft-nottingham-http-link-header-03

Hi Drummond,

On 02/12/2008, at 6:00 PM, Drummond Reed wrote:

> Section 2: Did you use the ABNF from RFC 2616 just for compatability  
> with
> that spec? RFC 3986, from which you also cite rules, uses RFC 2234,  
> which
> has since been updated to RFC 4234.

Yes. The main reason for this is the # rule, which is 2616-specific  
(although the HTTPbis editors are working hard to factor it out, that  
isn't ready yet).


> Section 3:
>
> 	A link can be viewed as a statement of the form "(subject) has a
> 	(relation type) at (object)"
>
> It struck me that the preposition "at" can be awkward when using this
> algorithm to describe some types of relations. Examples from some of  
> the
> link relations defined in 6.2:
>
> 	(subject) has a related at (object)
> 	(subject) has a payment at (object)
>
> An alternative would be:
>
> 	A link can be viewed as a statement of the form "the relationship
> 	between (subject) and (object) is (relation type)"
>
> In the case of the two examples above, this would yield:
>
> 	The relationship between (subject) and (object) is related.
> 	The relationship between (subject) and (object) is payment.

That doesn't imply direction very strongly. How about

A link can be viewed as a statement of the form "(subject) has a  
(relation type) resource at (object)."



> Also, have you considered mentioning that this is essentially an RDF
> subject/predicate/object triple?

How people interpret and process links is up to them.


> Section 5:
>
>   Each link-value MUST have at least one "rel" or "rev" parameter  
> whose
>   value indicates the relation type.  If the "rel" parameter is used,
>   it indicates that the link's direction for that relation type is
>   outbound; if the "rev" parameter is used, the given relation type's
>   direction is inbound.
>
> Is there any reason this requirement isn't reflected in the ABNF  
> itself,
> i.e.:
>
> 	Link           = "Link" ":" #link-value
> 	link-value     = "<" URI-Reference ">" ( rel / rev )
> 				*( ";" link-param ) )
> 	rel            = "rel" "=" relation-type
> 	rev            = "rev" "=" relation-type
> 	...

More than one of each is allowed; it gets kind of tortured if you try  
to reflect all of the constraints (although if you can come up with an  
elegant way to express them, I'm more than receptive).


> Also in section 5:
>
>   The context of links conveyed in the Link header field is the
>   representation that the header is part of.
>
> If the resource for which the Link header field is being returned is
> abstract, then it has no representation (only descriptions). Thus it  
> seems
> that it would be more inclusive to say:
>
>   The context of links conveyed in the Link header field is the
>   resource that the header is describing.

See the response I just sent to Eran.


> At the end of section 5:
>
>   Here, the link "http://example.org/" has outbound links of the types
>   "http://www.iana.org/assignments/relation/index",
>   "http://www.iana.org/assignments/relation/start", and
>   "http://example.net/relation/other", as well as an inbound link of
>   type "http://www.iana.org/assignments/relation/copyright".
>
> It was confusing to read "the link"..."has outbound links...". Per  
> your
> earlier wording, it seems it would be more precise to say:
>
>   Here, the link "http://example.org/" has outbound relation types
>   "http://www.iana.org/assignments/relation/index",
>   "http://www.iana.org/assignments/relation/start", and
>   "http://example.net/relation/other", as well as an inbound relation
>   type "http://www.iana.org/assignments/relation/copyright".

Looks good, thanks!


> In section 6.2:
>
> 	sgml-name      = ALPHA *( ALPHA | DIGIT | "." | "-" )
>
> Even if the SGML folks allowed it, I've generally understood it to  
> be bad
> practice for a token name to end in a symbol character. I know it  
> means
> mucking with their rule, but you could prevent that with:
>
> 	sgml-name      = ALPHA *( [ "." | "-" ] ALPHA | DIGIT | )

Hmm. I lifted this text from the original Link header in 2068; it's  
largely hear to assure some amount of backwards-compatibility. The BNF  
you propose introduces other constraints besides the one you're  
intending...


> Hope this helps,

Very much so, thanks again.



--
Mark Nottingham     http://www.mnot.net/

Received on Wednesday, 3 December 2008 02:27:43 UTC