- From: Sam Ruby <rubys@intertwingly.net>
- Date: Fri, 08 Apr 2011 10:11:50 -0400
- 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 UTC