Updated change proposal for ISSUE-27, was: ISSUE-27(rel-ownership) Call for Change Proposal advocates

On 10.11.2010 14:46, Sam Ruby wrote:
> ...
>>>> Note that the change proposal originated from Mark Nottingham; I'm not
>>>> sure whether it should be updated before a poll (reflecting publication
>>>> of RFC 5988, supporting web sites, and initial registrations), though.
>>>
>>> Just be aware: we only intend to survey and evaluate proposals which
>>> actually are received.
>>
>> Yes, but on the other hand all counter proposals were received after the
>> deadline.
>>
>> So I think it would be fair to actually allow Mark to look at the CP and
>> consider whether it needs an update.
>
> Fair enough: I wasn't clear. All I was trying to express is the
> sentiment that if we don't get an update, we will proceed with what we
> have. If we get an update before we proceed to a survey, we will
> evaluate whether or not to include it in the survey.
> ...

Hi,

Mark and I have spent some time updating the initial change proposal, 
mainly with respect to the status of the "Web Linking" specification and 
the IANA registry, but also adding refs to related issues (127) and 
notes with respects to concerns raised in the meantime.

See below.

-- snip --
Summary

This change replaces the Wiki link relation registry with that defined 
in RFC 5988 "Web Linking" [1], an IETF RFC on the IETF Standards Track, 
while aligning HTML5's use of links with that described therein.

Rationale

The link relation types defined in HTML5 are not specific to that 
format; their semantics can be reused in other formats, as well as by 
applications other than Web browsing. It is confusing for users to, 
potentially, have a relation type mean one thing in one application, 
whilst meaning something different when used in a different format.

Furthermore, using a wiki to register relation types, while attractive 
due to its simplicity, may not be a workable solution in the long run, 
because the criteria for inclusion, ratification, and deprecation are 
not well-defined. The current proposal also does not address dispute 
management and coordination issues, which Wikis generally address by 
nominating one or a group of administrators.

This change addresses these issues by leveraging the IANA registry 
defined in "Web Linking."

A few notes to address concerns raised previously:

  - Nothing prevents us setting up a Web form that allows people to make 
registration submissions, thereby streamlining and mostly automating the 
process of registering a new relation type (a prototype is online at 
<http://paramsr.us/link-relation-types/>).

  - The registry is extensible, so that HTML5 and others can add new 
attributes (e.g., how the referenced resource should be treated for the 
sake of archiving or storing something for offline use).

  - The registry is available in a machine-readable form, so that people 
can incorporate it in validators, etc.

  - The requirements for registration are low; for most relations all 
that you need to have is a stable document (e.g., a W3C Note, IETF RFC, 
publication on microformats.org). This isn't a closed list; e.g., 
'search' was registered with opensearch.org. whatwg.org is also a likely 
candidate.

  - The Designated Experts for the registry are currently Mark 
Nottingham, Julian Reschke and Eran Hammer-Lahev. There is a 
well-defined process for escalating issues and replacing them, if necessary.

  - If the HTML community has specific concerns or requests, the DEs 
would like to hear them, so that the registry can give the most benefit 
to the most people.

Details

1) Define the link, a, and area elements in terms of the Web Linking 
framework; i.e., in terms of "target IRI", "context IRI", "relation 
type" and "target parameters."

2) Change the relation types defined in "Link types" to be registrations 
or references to existing relations (as appropriate) in the Link 
Relation Type Registry.

3) Add fields to the Link Relation Field Registry for "Effect on HTML5 
Link Element" and "Effect on HTML5 A and Area Elements", and populate 
registrations as appropriate. (But see [2] for a request to tune the 
actual field definitions)

4) Change "Other link types" to refer to "Web Linking" for registration 
procedures.

5) Review initial registry contents in Web Linking to assure that 
semantics defined there align with HTML5's.

Impact

Positive Effects

- Link relations will be usable across formats, and aligned with Atom's 
already existent relation types

- Well-defined registration process with change controllers, conflict 
resolution, long-term maintenance

Negative Effects

- None known.

Conformance Classes Changes

None known.

Risks

None.

References

[1] <http://tools.ietf.org/html/rfc5988>
[2] <http://www.w3.org/html/wg/tracker/issues/127>

Received on Tuesday, 16 November 2010 08:39:06 UTC