W3C home > Mailing lists > Public > public-html@w3.org > April 2011

Working Group Decision on ISSUE-27 rel-ownership

From: Sam Ruby <rubys@intertwingly.net>
Date: Fri, 08 Apr 2011 10:11:50 -0400
Message-ID: <4D9F17A6.5070100@intertwingly.net>
To: HTML WG <public-html@w3.org>
The decision follows.  The chairs made an effort to explicitly address
all arguments presented in the Change Proposals on this topic in
addition to arguments posted as objections in the poll.

*** Question before the Working Group ***

There is a basic disagreement in the group as to where @rel values
should be registered.  The result was an issue, three change proposals,
and a straw poll for objections:

http://www.w3.org/html/wg/tracker/issues/27
http://lists.w3.org/Archives/Public/public-html/2010Nov/0273.html
http://www.w3.org/html/wg/wiki/ChangeProposals/RelRegistryAtTheW3C
http://www.w3.org/html/wg/wiki/User%3AEoconnor/ISSUE-27
http://www.w3.org/2002/09/wbs/40318/issue-27-objection-poll/results

Additionally we received a late and incomplete proposal that was not
considered in this decision as objections were not solicited against
that proposal:

http://lists.w3.org/Archives/Public/public-html/2011Mar/0497.html

Finally we received some feedback on survey responses which were
entered just before the survey closed, not allowing adequate
opportunity for rebuttal:

http://lists.w3.org/Archives/Public/www-archive/2011Apr/0041.html

== Uncontested observations:

We have three proposals, two of which listed negative effects and
risks:

* HTML-specific registrations might not be reusable in other contexts
   with the same semantics.

* Registering the same token with different meanings for HTML and
   another format that uses "rel", such as Atom, might cause confusion.

* This change proposal, if adopted, would result in HTML link relations
   remaining separate from Atom and HTTP link relations. This is
   negative to those who have a goal of converging Atom, HTML, and HTTP
   link relations into a unified system.

Additionally, the proposal for a W3C Registry included:

* The registry would be not be the Microformats Wiki even though the
   Microformat community has the best track record for running a
   registry of rel values.

* Multiple registries for rel values may cause some confusion.
   Operating a registry at the W3C may not be viewed favorably by people
   operating competing registries. With a W3C registry in place, people
   might still not bother to register values or might opt to register
   them in one of the competing registries instea

The proposal for the Microformats Registry included:

* we might have to update the spec at some point in the future if for
   whatever reason the registry moves to another URL

The people who advocated these proposals felt that the benefits of
their proposals outweighed these disadvantages.  Others clearly
disagreed.  The fact that theses considerations were acknowledged up
front was appreciated.

=== rel values: media specific or media independent?

While it was uncontested that the choice in location of a registry
would have an impact on what could be registered, there clearly wasn't
consensus on whether such policies would be a benefit or a problem.
Two quotes from the survey best illustrate this divide, first one
against the RFC 5988 proposal:

   The main issue with this change proposal is that it unifies relation
   types across multiple protocols and document formats. The rel=""
   attribute in HTML applies just to HTML; other formats, including
   metadata outside documents, have different needs and rel="" values
   should not therefore be forced to have a consistent meaning no matter
   where they show up.

Next one against both the W3C and Microformats proposals:

   The main issue with this change proposal is that it doesn't unify
   relation types across protocols and document formats. Link relations
   apply to many non-HTML formats, and also occur as metadata outside
   documents, and should have a consistent meaning no matter where they
   show up. In particular, if they are not consistent than the
   specification will have to consider this when discussing the
   interaction between <link> and the HTTP Link header field.

While both statements use the word 'issue', neither contain much in the
way of evidence or operational difficulties expressed in quantitative
terms.  Other statements make various claims, and we evaluate each in
turn now:

   I believe that having consistent definitions would be useful (for
   instance, when translating between formats), and that the additional
   work of defining the relation in a format-agnostic way is both small
   and worth the effort.

This is more of an assertion than a measurable quantity or the results
of an observation.  By contrast the opposite was asserted here:

   http://lists.w3.org/Archives/Public/public-html/2010Aug/0161.html

Additional evidence of operational difficulties:

   Must be able to register HTML-specific detail's" --> see ISSUE-124 and
 
<http://www.ietf.org/mail-archive/web/link-relations/current/msg00182.html>;
   so this is work-in-progress as of last weekend.

The operational terms in the referenced email "quite some overhead",
and that was from a proponent of this option.

   There is currently no evidence that divergent semantics of relations
   is desirable across formats and protocols (the interests of
   interoperability would suggest otherwise)

This objection uses the word "desirable" and may be true as stated.
What is at issue isn't "desirable" but rather something more like
"necessary at times".  ISSUE-124 (cited above) is an example where
others feel that it may be necessary in certain circumstances to have
some relations differ between two formats or protocols.

   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.

"Potential" confusion is uncontested, however lacking citation of
specific examples of confusion this objection is treated as weaker than
the actual problems that have been identified in specific cases.

   Relation names are not media-type specific, and they have been around
   a lot longer than the source documents being used for that page

The length of time these values have been around is uncontested, but
the assertion that these names are not media-specific is being made
here without anything resembling evidence.

   From an architectural perspective, I strongly object to any notion
   that link relations are specific to a media type. They are orthogonal
   in Web architecture (always have been and always will be)

Again, an assertion without any evidence.

A statement from the Change Proposal for a "Rel Registry at the W3C":

   There isn't general agreement that a higher level of abstraction and
   generality is worth the trouble.

... and a statement from the Change Proposal to "Defer to the
Microformats community for cataloging HTML rel values":

   All HTML rel values, whether defined in the HTML specification,
   registered in whatever scheme we end up choosing, or minted by web
   authors and unregisterd, are case-insensitive tokens.

   RFC 5988 requires unregistered rel values (what it calls Extension
   Relation Types) to be URIs. Formats which allow Extension Relation
   Types to be expressed as simple tokens are required to provide a
   mechanism for them to be converted to URIs for comparison.

A strong, unaddressed, and possibly unresolvable, issue with the idea
that link relations can ever be media independent.

   This WG has made no decision on whether or not unification of Atom
   and HTML rel values is a goal we should pursue.

We agree with these observations.

Finally, a statement made in the context of a purported "positive
effect":

   People registering rel values don't need to consider how to
   generalize their registration to apply to other formats, such as Atom
   or PDF.

Clearly there is a disagreement as to whether or not this is a good
thing.  In fact, the overall sentiment seems to be that it is
unfortunate and a potential source of confusion if the same names are
used for different meanings in different contexts.

Overall, however, the case was not made for the architectural principle
of relationship values being media independent, and any objections
based on this premise were therefore considered to be weak.

Finally, we are aware of an assertion that the Microformats wiki is
intended to be format-agnostic:

http://microformats.org/wiki/rel-registry#Can_the_microformats_rel_registry_document_HTML_specific_details

Whether or not this has been adequately demonstrated is in dispute.
However as the case has not been made that relationship values are
media independent, even if this assertion does not turn out to be true,
it will not constitute a strong objection.

=== Objections to the proposal to continue to use the RFC 5988 registry

First, from the survey:

   IANA does not have a good track record of operating registries that
   affect formats higher up in the protocol stack. ... To make this
   worse, despite claims to the contrary, IANAs registration process is
   so heavy weight that many people give up. ... While IANA has claimed
   that changes can be made to improve the situation, so far it doesn't
   appear that these changes have been made giving me little reason to
   believe that they will in the future. And no reason to believe that
   they'll be made in a satisfactory way. ... If IANA want to be
   responsible for running the rel registry I think they need to prove
   themselves first.

These claims are found to be strong.  In addition, there is evidence
cited in the previous section which backs up these claims.

   There are known problems with the IANA registry in not reflecting
   current practice, but such problems can occur with any registry.
   Adding another registry to the ecosystem does not close the door to
   such problems, rather it adds another point of failure.

This attempts to equate "known problems" with one registry with
potential problems with another.  All this does is reinforce the notion
that the RFC 5988 registry is problematic for the purpose of
registering HTML rel values.   It might also be a weak objection
against the creation of a new registry from scratch.  However, lacking
specifics, it is not treated as a valid objection against an existing
registry like the Microformats wiki.

   Yes, the use of RFC 5988 unifies relations defined by the Link:
   header, but its scope is limited to just that.

While this was intended as a defence for the RFC 5988 registry, it
ended up reinforcing the reasons why such a registry is not appropriate
for this usage.

   Understanding/use/participation in the registry defined in RFC 5988
   is far too difficult, and frankly, inaccessible due to the length and
   cryptic/technical/jargon wording

This objection lacks specifics and was disputed.

   Empty promises / hidden work. The Change Proposal uses the phrase
   "Nothing prevents us ..." and these show holes. Every such
   encouragement to do something indicates known shortcomings in use of
   IANA/RFC5988 and some amount of hidden work in order to make this a
   workable solution.

This objection lacks specifics and was disputed; other objections which
contain specifics were taken to be stronger objections.

   Misleading / out of touch. The proposal says "requirements for
   registration are low" - this is misleading or fails to understand the
   audience for adding rel values. Understanding/following RFC5988 is
   *not* a low requirement, e.g. see 1. above, rather it is quite
   onerous and demanding of a high level of technical comprehension and
   patience, making it inaccessible to perhaps most web authors, many of
   whom have proposed rel value in microformats.

Again, this was disputed.  Even if it were valid it would not be
considered as strong as other objections which provide specifics.

   Too many steps. The HTML5 editor had difficulty with the number of
   steps required with RFC5988 rel registrations. There is no documented
   short list of the steps to take, web form to use, etc.

We have an instance cited where one individual failed to produce a
satisfactory outcome; and another instance cited where another
individual succeeded.  This perhaps discredits that the claims of "low
barrier to entry" and perhaps indicates that the documentation should
be improved; either way this is not the strongest objection and was not
evaluated further.

   No provisional registration. There is no mechanism for simple
   brainstorm proposal documentation of in-development rel values, e.g.
   for the purpose of easier discovery for collaborative development and
   collision avoidance.

This uses a purported strength of one proposal can be viewed as a
comparative weakness of another proposal.  This is certainly a valid
approach in general, but in the case this proposal the objection
provides little in the way of rationale or evidence, and the failure to
do so affects the assessment of the strength of this objection.
Furthermore we have a statement that a 'DE will be happy to enter the
registry as "pending"'

   Apparent dependency on email. RFC5988 says "sent to the
   link-relations@ietf.org mailing list" - email is a primitive tool for
   this, and given that there are known solutions using wikis, web forms
   etc. those should be preferred.

Like the objection cited above, lacking specific evidence this is
treated as a mere assertion and not as the strongest objection.

   Designated Expert bottleneck. RFC5988 says "the Designated Expert(s)
   will either approve or deny the registration request" whereas it is
   much more desirable to simply have any/all attempted registrations be
   public in some sort of provisional or brainstorm status by default,
   and only then optionally acted upon by experts.

Like the objection cited above, lacking specific evidence this is
treated as a mere assertion and not as the strongest objection.

   Failure to cite original/active specs. RFC5988 "Initial Registry
   Contents" lists for example "license" which links to RFC4946 which
   itself fails to cite the *actual* rel-license specification from
   which it took a snapshot: http://microformats.org/wiki/rel-license.

A potentially valid objection, the only reason it was not evaluated
further was the existence of clearly stronger objections.  It was also
agreed that the RFC 5988 registry should be corrected in this instance.

   Failure to perform even trivial research/linking. The RFC5988 entry
   for "payment" says "Notes: this relation type registration did not
   indicate a reference." Googling "rel payment" returns the
   microformats draft for rel-payment:
   http://microformats.org/wiki/rel-payment which should have been
   referenced by RFC5988. This real world example is indicative of a
   process/thoroughness breakdown.

A potential failing of designated experts, and potentially a valid
objection; the only reason it was not evaluated further was the
existence of clearly stronger objections.

   Unfriendly to / misleading regarding microformats. The proposal says
   "a stable document (e.g., a W3C Note, IETF RFC, publication on
   microformats.org)." and yet NONE of the entries on
   http://www.iana.org/assignments/link-relations/ reference
   microformats.org specs/drafts for those rel values which were/are
   developed and maintained on microformats.org like: license, nofollow,
   payment, tag.

Lacking evidence that anybody actually attempted to register these
drafts and failed, this objection was not given any weight.

   If the barrier to rel value registration is too high, common rel
   values will fail to be registered. This has already happened with the
   RFC 5988 registry (rel=pingback, one of the top 25 most common rel
   values in use, is just one example of this). Should we adopt this
   registry, we would put Web authors wanting to use such rel values in
   the situation where they have to choose between using the rel value
   on the one hand and producing conformant HTML on the other.

Unlike previous objections which talked abstractly about barriers to
registration, this one provides specifics and therefore is treated as
strong.  The reason given why rel=pingback was not included:

   Because we haven't got a spec that the designated experts (including
   myself) consider stable enough; note that this affect both content
   and location

This relates back to previous concerns about barrier to entry.

Returning back to evaluating objections:

   can't have the relation appear in the registry with a single
   registration action but is on the hook for defending his/her
   registration over the course of multiple email round trips to the
   Designated Experts and during this time the relation doesn't appear
   in the registry.

Again this speaks indirectly to barrier of entry, but lacking in
specifics and lacking any direct association of this with a
demonstrable harm, this objection is not treated as strong.

   there's no provisional registry. But there is an issue tracker that
   can be used to track registrations that are work-in-progress

While a provisional registry was listed as a potential positive of
another proposal; it wasn't clearly established as a hard requirement.
Therefore this lack isn't treated as a strong objection.

Finally, we have this listed as a rationale and positive effects of the
"Rel Registry at the W3C" which in turn could be seen objection to this
proposal:

   Changing how the IETF/IANA operate to satisfaction seems to involve
   considerably more discussion and time than setting up an
   HTML-specific rel registry elsewhere

   People will be able to register HTML-relevant rel values with less
   bureaucracy than at the IANA, which may lead to the registry better
   reflecting usage.

   The HTML WG can proceed without getting further entangled in
   trying to change IETF or IANA policies or practices.

Further evidence of strong objections to using RFC 5988 for a registry
for HTML rel values.

=== Objections to the proposal to create a W3C registry

In this section we group together a number of related comments by
various sources, and analyze them collectively.

   Registration difficulty: Since 'ratified' status of the
   XPointer-inspired registry depends on a W3C spec or Microformats
   approval, Ian's test registration attempt (which was of his private
   spec) would have resulted in a 'proposed' state registration for at
   least as long as the RFC5988-registry refused to take it in.

   Reality reflection: Unlike the initial RFC5988-registry, this CP says
   that only relations with a W3C or Microformats specifications in
   their back, can get 'ratified' status. This is a higher bar than
   RFC5988 has (which only lists 'ratified' relations, though). It would
   also be a barrier to reflect 'reality' as it seems like link types
   from specs outside W3C/Microformats, can only reach 'proposed'
   status. Even the XPointer schem registry does not have a similar
   barrier - as there the specs for the schemes can be located
   everywhere.

   it looks like some relations could end up as 'proposed' for ever. And
   it is not clear why a 'proposed' state forever is useful.

Taken together, complete with citing a specific instance of a problem,
this is treated as a valid objection.

   A new registry: The net result could easily be that we get two
   registries - a RFC5988-registry and this registry. Were this registry
   often would be like a preparatory registry for RFC5988-regstriation.
   OTOH, we could also get a situation where not everything in RFC5988
   would/could be 'ratified' in this registry because it does not appear
   in W3C or Microformats space.

   Lack of testing: Unlike both Microformats and the RFC5988 registry,
   there is no testing and track record.

   No experience. There is no experience with W3C hosting a rel values
   registry other than the HTML specifications. With that experience
   alone the update cycle is too slow (with perhaps the exception of the
   HTML5 editor's draft which is updated quite frequently, however has a
   single-editor bottleneck).

   Is the W3C indeed *willing* to run registries? This seemed to be
   unclear when we discussed this as TPAC Lyon.

   We don't know if the W3C Membership is willing to commit technical or
   financial resources to running a rel value registry. (Remember, the
   XPointer specification didn't establish the XPointer registry, it
   simply reserved all short names to the W3C. The Director then sought
   and received AC approval to establish a registry.) That said, the
   advancement of the HTML spec along the recommendation track could be
   taken as agreement to run a registry from the Director and
   Membership.

A proposal brought forward which critically depends on an allocation of
resources by an organization without a prior commitment by that
organization to do so is also treated as a valid objection.

   My understanding is that users will be required to obtain a W3C
   "Public Account", which requires registering (with a real name), and
   may not be fully automated. This may indeed be a higher barrier than
   simply sending an email to the IANA link relations mailing list.

   Anticipated higher barrier to entry. Speaking in theory (since there
   is no such registry yet) and based on experience in other W3C
   efforts, the process that is expected to be required will likely be
   more work than simply editing a wiki page.

All proposals require some barrier to entry, if for no other reason
than to eliminate spam.  What that precise level should be is
apparently not something we have consensus.  However given the lack of
specifics (which to be fair is impossible as this registry doesn't
exist yet), this objection is not given any direct weight.  Instead it
is viewed as supporting the previous arguments against the W3C having a
track record in administering registries to point to.

Finally, we have this listed as a positive effect of the IANA proposal,
which in turn could be seen objection to the remaining proposals:

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

In the context of this change proposal, this was treated as giving
additional strength to the argument on the basis of the W3C not having
established a track record in maintaining registries.

=== Objections to the proposal to make use of the microformats WIKI

Again we found a number of related comments worth group together and
analyzed collectively.

   Is the software capable of supporting the machine readability use
   case that was mentioned?

   I recall people asked for machine-processable content of the registry
   (for validators). How does the Microformats Wiki address this?

A potentially valid objection.  However as it was not established that
use case mandatory vs merely desirable, this argument was considered
weak.  Nor was there evidence that the Micoroformats Wiki can not
satisfy this use case.  The "impact" section of the "Defer to the
Microformats community for cataloging HTML rel values" gives some
indication that it may be possible.

   I perceive Microformats as more "private" than the RFC-based and
   W3C-based option. Both inside the RFC-based option and the W3C
   option, the Microformats specs have a room. Whereas it is not as
   clear to me how IETF/IANA and W3C have a room inside Microformats.
   Also, while the CP speaks about provisional registration, where does
   it speak about formal registration? Can a W3 spec specify a link
   relation without it getting into the Microformats registry? Just
   because Microformats serves well as a specification development
   platform does not mean that it serves well as a registry. I also
   doubt that each and all of its specs are given much heed to. jTake
   for example nofollow. Did it not appear in Google somewhere first?
   The Microformats spec is just a post-blessing. This hints that it is
   not a place which potential registrants 'default' to use when they
   want to register something. (It might be a place some default to use
   to *develop*, but not for registering.) One should keep specification
   and registration separate as this ensures that registration can be
   taken from more sources - it should not need to become a Microformats
   spec before it can be registered. Both the other two options maintain
   such a separation between specs and registry.

This is mostly speculation and lacks specifics.  Had this objection
analyzed the contents of the existing page and found there to be an
actual problem, this would have been treated in the same way as the
"Failure to cite original/active specs" objection to the RFC 5988
proposal, i.e., as a potentially valid objection which was not
evaluated further in the presence of stronger objections.

   The page
     http://microformats.org/wiki/existing-rel-values
   defines relation names in terms of recent HTML practice and specs,
   mostly microformat specs. All prior HTML practice and Web relations
   are either missing or incorrectly defined in that page.

No evidence is provided that there ever was an attempt made to correct
this, nor any indication of what the results was or would have been if
this had been done.  As such, this was treated as a weak objection.

   XFN foolishly redefines many common relations (e.g., "child") and
   that page incorrectly treats XFN as authoritative (as opposed to
   listing all of the specifications that have defined "child"). It
   should be no surprise, therefore, that people outside of the
   microformats community do not consider it a valid registry of names
   for the Internet in general -- not even for HTML's use.

This starts out with an assertion that there is a "foolish"
redefinition, notes that only one spec is linked, and then attempts to
draw a conclusion from this data.  No evidence is provided that there
ever was an attempt made to correct this, nor any indication of what
the results was or would have been if this had been done.  As such,
this was treated as a weak objection.

   the registry at
     http://www.iana.org/assignments/link-relations/link-relations.xml
   is already more complete and accurate than the microformats page.

   It is proof, even with a very short existence, that IANA can be used
   as a registry for link relations and is far more reliable in doing so
   than the microformat wiki because it does not prefer microformats
   over all other link-defining hypertext.

Again, an attempt to draw an inference from a small amount of data, in
this case a single data point.  By contrast the proposal to "Defer to
the Microformats community for cataloging HTML rel values" does have an
analysis of the top 25 unique rel values, and comes to a completely
different conclusion.  As this objection fails to make this case, the
objection itself was treated as weak.

Finally, we have this listed as a positive effect of the IANA proposal,
which in turn could be seen objection to the remaining proposals:

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

In this case, the objection was viewed to be weak as it does not cite
any specific unresolvable issues with the Microformat's wiki.  A wiki
which has a demonstrable track record available to public inspection.

   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.

While this was originally intended as an objection to a different
proposal, it partially applies here.  Again as the Microformat wiki has
been around for a while and this objection does not cite any specific
unresolvable issues, this objection is not treated as a strong one.

*** Decision of the Working Group ***

Therefore, the HTML Working Group hereby adopts the "Defer to the
Microformats community for cataloging HTML rel values" Proposal for
ISSUE-27:

   http://www.w3.org/html/wg/wiki/User%3AEoconnor/ISSUE-27

Of the Change Proposals before us, this one has drawn the
weaker objections.

== Next Steps ==

Bug 8793 is to be REOPENED and marked as WGDecision.

Since the prevailing Change Proposal does call for a spec change, the
editor is hereby directed to make the changes in accordance to the
change proposal.  Once those changes are complete ISSUE-27 is to be
marked as CLOSED.

Additionally, we have the following request:

   If we adopt this Change Proposal, this WG should seek to have the
   IANA registry updated to explicitly disclaim that it should be used
   for HTML rel values.

While outside of the scope of this issue, we agree in principle with
this request.

== Appealing this Decision ==

If anyone strongly disagrees with the content of the decision and would
like to raise a Formal Objection, they may do so at this time. Formal
Objections are reviewed by the Director in consultation with the Team.
Ordinarily, Formal Objections are only reviewed as part of a transition
request.

== Revisiting this Issue ==

This issue can be reopened if new information come up. Examples of
possible relevant new information include:

* Specific evidence that the "existing rel values" page on the
   Microformats wiki is problematic for the intended use of registering
   values for the rel attribute in the scope of the HTML5 specification.
   Ideally such evidence would cite multiple good faith efforts to
   contribute to this wiki page and explain why such efforts failed to
   produce desirable results.

* Specific evidence that the majority of the arguments used against the
   IETF/IANA registry or the W3C registry are no longer true due to
   possible process changes at IETF/IANA and/or a stronger W3C
   commitment to and experience in supporting registries.  This kind of
   evidence when combined with negative experience (see above) with the
   Microformats wiki would be considered even stronger.

* Demonstration of actual harm caused by not requiring rel values to be
   strictly media independent in all cases.  Ideally such demonstration
   would be accompanied by concrete suggestions on how to resolve any
   existing cases of divergence, and evidence that of the positive
   effects of doing so.

=== Arguments not considered:

We have a number of statements in change proposals and in response to
the survey that appear were not considered for various reasons.  These
are cited here, followed by an explanation as to why they were not
considered.

   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

We only consider proposals which actually are brought forward.

   this proposal makes a lot of sense if we indeed *do* decide that
   harmonization between formats using link relations is not important.

We are looking for objections.  Additionally, this could have been seen
as an indication that the objection on the basis of failing to unify
rel values across media formats was not considered as a strong
objection by the person making this statement.

   This could be addressed by the Microformats community embracing a
   broader view of link relations, but as far as I know, nobody has made
   a concrete proposal for that (nor could this WG tell the Microformats
   community what to do).

Lacking such a concrete proposal, we did not evaluate the statement any
further.

   I'd be ok with this, but I think it would be even better to apply the
   proposal in
   http://lists.w3.org/Archives/Public/public-html/2011Mar/0497.html to
   this one.

A self identified weak objection with a reference to an incomplete
proposal which was not submitted in the time alloted.

   It would be good to know in which way the CP author *expects* the
   registry to change.

If such expectations were expressed, they could have been considered as
the basis of objections; but any such expectations which were not
expressed were not considered.

   I'll probably propose to move the meta/@name registry as well.

Out of scope for this issue, and not proposed.

   The registry we adopt should be available under a license compatible
   with both Free and proprietary software. The existing-rel-values page
   of the Microformats wiki is in the public domain, and as such its
   contents are able to be incorporated into Free software as well as
   proprietary software

Nobody clearly identified this as a problem with any of the three
proposals.

   Compared to the WHATWG wiki, the registry will be maintained on a
   site with multiple sysadmins responding to failure situations and
   with more resources to enable the longevity of the registry URL.

We don't have any proposals to continue with the WHATWG wiki.

   Whether a format or protocol relies on this header for its definition
   is a separate matter...  there is nothing to preclude the use of a
   different header for the purpose.

We only evaluate proposals which actually were put forward.

   Generally I think the use of URIs for rel values should be encouraged
   over the use of a registry anyway to avoid centralised points of
   failure

We only evaluate proposals which actually were put forward.

   XPointer schemes have generally been easy to register, and we see no
   reason to expect a new W3C registry to be substantially worse than
   its precedent.

This was entered in the spot where objections to a registry to be
hosted by the W3C are asked for.  In this context, it is not clear what
this statement is objecting to.

   what remains to be seen is whether it offers a route for
   provisionally registered values to be achieve full registration.

   The process of becoming a microformats admin is opaque and does not
   appear to follow democratic or indeed easily understood
    principles.

These were not the subject of any objection found in any change
proposal or entered during the survey; instead it was a question that
was asked and answered on the mailing list.  The reason that it is
listed here is that it was referenced in an email purported to be a
response to feedback provided late in the survey, and leads to a
suggestion that the survey be restarted.  As this discussion was not a
factor of the decision we see no reason to restart the survey.  Should
specific problems be found with the Microformats registry, that could
be submitted as potential New Information that could cause this issue
to be ultimately reopened.

   Diversity and openness of maintainership

As a part of the rationale for Microformats proposal, it possibly could
be construed to be a potential criticism of the remaining two
proposals.  However lacking any specifics with respect to the
alternatives, even if this were intended to be an objection, it would
not be given any weight.
Received on Friday, 8 April 2011 14:12:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:27 GMT