- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 3 Dec 2008 13:27:03 +1100
- To: Drummond Reed <drummond.reed@cordance.net>
- Cc: <www-tag@w3.org>, <ietf-http-wg@w3.org>
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:49 UTC