W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2008

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

From: Drummond Reed <drummond.reed@cordance.net>
Date: Fri, 5 Dec 2008 23:04:24 -0800
To: "'Eran Hammer-Lahav'" <eran@hueniverse.com>, "'Ian Hickson'" <ian@hixie.ch>, "'Phil Archer'" <phil@philarcher.org>
Cc: <ietf-http-wg@w3.org>, "'Mark Nottingham'" <mnot@mnot.net>
Message-ID: <986147C176174C67A88720C0758DAA29@ELROND>

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.

=Drummond 

> -----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
Received on Saturday, 6 December 2008 07:05:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:50:58 GMT