Re: Feedback for draft-nottingham-http-link-header-03

Drummond Reed wrote:
> Eran asks a really good question and I don't have the experience to answer.
> I'm coming from an XDI RDF perspective where the ability to express both
> inbound and outbound links is very useful. But I understand how tricky and
> confusing such semantics are for authors who are not steeped in that type of
> stuff.
> 
> My only input is: a) if "rev" is going to be useful anywhere, it's in
> discovery, and b) if "rev" is dropped, keep "rel" to just outbound links.

+1

However, Hixie's argument against rev actually highlights my unease 
about dropping it from HTTP Link. It's the same basic argument used by 
the WHAT WG to decide whether to keep or remove features in HTML 5. On 
the surface it's an attractive one: if no one uses a feature properly, 
or worse, where a feature is used it's generally used improperly, then 
it should probably be dropped. The flaw with the argument is that it can 
only ever lead to a diminishing feature set and imposes restrictions on 
current and future use cases.

Yes, the use of rev in RDFa is still largely theoretical on account of 
RDFa still being relatively new, but if you handicap it by giving the 
impression that rev /in general/ is deprecated then you weaken the 
thrust of the community here which, as I understand it, is doing its 
level best to improve discovery and semantics.

For me the semantics of rel and rev are clear enough - the only 
difference between them being that rel is outbound and rev is inbound. 
There is, however, a much greater difference in the trust one might wish 
to put in those links - and trust is a human quality not easily encoded 
in bytes. Take these examples:

Link: </styles.css>; rel="stylesheet"; is something an agent has little 
reason not to trust as the likelihood of it being true is high and the 
consequence of it being false is small. It is effectively an assertion 
by the resource creator that the stylesheet should be applied to it.

The following relationship is not so dissimilar.

Link: <http://cool_for_kids.example.org>; rev="recommends";

It's an assertion by the resource creator that a third party has 
recommended it for kids. A user agent would be wise to check with 
cool_for_kids.example.org before taking the assertion as true - but the 
direction doesn't alter the basic fact that the resource creator is 
making the assertion in both links.

To emphasise this a little, try these two:

Link: <foo.bar> rel="describedby";
Link: <foo.bar> rev="describes";

Here the rel/rev values are the inverse of each other so that in effect 
the same relationship is being asserted in two different ways and there 
is no obvious reason to put more weight in one rather than the other.

Most Links will use rel, not rev, but if we can clearly articulate the 
semantics as being equal and opposite, whilst making it clear that this 
says nothing about trust, then perhaps we can retain rev and leave the 
door open to future possibilities.

POWDER can live without rev in HTTP Link, but my gut feeling is that it 
should stay if possible.


Phil.

>> -----Original Message-----
>> From: Eran Hammer-Lahav [mailto:eran@hueniverse.com]
>> Sent: Friday, December 05, 2008 10:20 PM
>> To: Drummond Reed; 'Ian Hickson'; 'Phil Archer'
>> Cc: ietf-http-wg@w3.org; 'Mark Nottingham'
>> Subject: RE: Feedback for draft-nottingham-http-link-header-03
>>
>> The key question is what interoperability value does 'rev' add vs. the
>> potential confusion is might cause (I am not trying to imply an answer
>> here). The way I understand is, Link header was defined in RFC 2068 and
>> dropped in 2616 due to lack of implementations and experience using it
>> during that time period. The reason it is being brought back now is
>> because between ATOM, HTML, and some experimentations with the Link
>> header, it seems like we have gained the experience needed to define it as
>> part of the protocol. Using the overall logic, is there sufficient
>> experience using 'rev' values to include it in the current proposal
>> (again, asking not implying)?
>>
>> EHL
>>
>>
>>> -----Original Message-----
>>> From: Drummond Reed [mailto:drummond.reed@cordance.net]
>>> Sent: Friday, December 05, 2008 9:53 PM
>>> To: 'Ian Hickson'; 'Phil Archer'
>>> Cc: ietf-http-wg@w3.org; Eran Hammer-Lahav; 'Mark Nottingham'
>>> Subject: RE: Feedback for draft-nottingham-http-link-header-03
>>>
>>>>> On Wed, 3 Dec 2008, Phil Archer wrote:
>>>>>
>>>>> HTML 5 has dropped rev for the link element and if the tide is
>>> against
>>>>> keeping rev in HTTP Link then the impression being given might be
>>> that
>>>>> rev is deprecated everywhere.
>>>> On Friday, 5 Dec 2008, Ian Hickson wrote:
>>>>
>>>> Eran asked me to chime in here to give some background on why HTML5
>>> drops
>>>> the "rev" attribute.
>>>>
>>>> It basically boils down to reducing author confusion. As can be seen
>>> from
>>>> this thread, even people quite familiar with Web standards and
>>> semantics
>>>> have trouble defining exactly what it means. We did some research and
>>>> found a quite startling situation: the most common value for rev=""
>>> in the
>>>> HTML pages we examined was rev="made", which is equivalent to
>>>> rel="author", and the second most common value was rev="stylesheet",
>>> which
>>>> is a typo. The remaining values were so too rare to examine. Further
>>>> evidence that there was confusion: rel="made" was a common rel=""
>>> value,
>>>> though it is likely that in most cases it should have been rev="made"
>>> or
>>>> rel="author".
>>>>
>>>> What we concluded from this was that despite the feature (rev="")
>>> being
>>>> available for a decade or more, authors don't need it, and don't
>>>> understand it.
>>> It seems like a reasonable conclusion relative to HTML authoring.
>>>
>>>> We can help authors by making this that they usually misuse invalid,
>>>> because then the validators will catch their errors. (Right now, an
>>> HTML4
>>>> validator can't strictly say that rev="stylesheet" was an error, and
>>> so
>>>> the error goes undetected even by authors using QA tools.)
>>>>
>>>> The data was published here:
>>>>    http://code.google.com/webstats/2005-12/linkrels.html
>>>>
>>>> (More recent but unpublished studies have shown similar results in
>>> larger
>>>> and more recent datasets.)
>>>>
>>>> The above was weighed against the (currently mostly theoretical) need
>>> for
>>>> rev="" in various fields, such as RDFa, some Microformats, and so on,
>>> but
>>>> on the balance we decided that the immediate help to authors was
>>> worth
>>>> more to authors and users than these use cases. Helping with this was
>>> the
>>>> realisation that rel="" values could always be minted in a way that
>>> was
>>>> equivalent to rev="". For example, if someone had rel="foobar" and
>>> really
>>>> wanted rev="foobar" to be available too, they could instead just
>>> define
>>>> and use rel="rev-foobar".
>>> Some recent feedback on Link Header highlights a serious issue with
>>> that
>>> workaround. Even if HTML5 drops "rev", it doesn't change the semantics
>>> established in HTML4, RDFa, and other uses that "rel" and "rev" assert
>>> outbound and inbound links, respectively. So to start saying that
>>> _some_
>>> uses of "rel" can assert inbound links by inserting special semantics
>>> _into
>>> the value_ of the attribute would appear to invite a real semantic
>>> mess.
>>>
>>> Much better to either: a) drop support for "rev" but leave "rel"
>>> unambiguously asserting outbound links, or b) define a whole new
>>> attribute
>>> that explicitly takes link directionality semantics out of the
>>> attribute
>>> definition and puts them into the attribute value.
>>>
>>> =Drummond
> 
> 
> 

-- 
Phil Archer
w. http://philarcher.org/

Received on Saturday, 6 December 2008 08:31:07 UTC