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 06:21:00 UTC