- 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>
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 UTC