Working Group Decision on ISSUE-120 rdfa-prefixes

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 whether prefixes are
confusing and should be removed, or if the documententation should
merely be updated to clarify that they are an optional feature.  The
result was an issue, two change proposals, and a straw poll for
objections:

http://www.w3.org/html/wg/tracker/issues/120
http://wiki.whatwg.org/wiki/Change_Proposal_for_ISSUE-120
http://www.w3.org/html/wg/wiki/ChangeProposals/RDFaPrefixesNoChange
http://www.w3.org/2002/09/wbs/40318/issue-120-objection-poll/results

== Uncontested observations:

The following observations were found not to be controversial:

* use of prefixes is optional in RDFa, and therefore technically
   unnecessary

* xmlns: /only/ exists in HTML5 for backwards compatibility reasons, it
   is deprecated, HTML5 authors should not use it.

Neither of these were decisive.  There were people who supported either
of these proposals even after taking these facts into consideration.
The fact that they were acknowledged up front was appreciated.

Furthermore, we found no arguments against the clarifications proposed.
Instead some argued that the clarifications were insufficient.  As such
the only matter that needed to be decided is whether or not a prefixing
mechanism is to be retained or removed.

=== Positive effects

We start by looking at the purported positive effects listed in each
change proposal.  In one change proposal, we have a statement that
complexity is inhibiting adoption.  In the other, we have an objection
to a change that would affect the ability to parse existing content,
and an argument for consistency with other standards (specifically
XHTML).

 From the change proposals, we have data suggesting "hundreds of
millions of documents" comprising 3.6% of the web uses non-trivial RDFa
and that there has been 510% growth over a 19 month period.  This leads
us to conclude that adoption has not been a significant issue, as such
we turn our focus to evaluating the specific objections to the "Clarify
how prefixes work in RDFa, and that they're an optional feature."
Change Proposal to see if we can find an objection stronger than
"breaks existing content".

=== Simplicity

We start by evaluating a number of assertions and evidence that
namespaces lead to confusion (sometimes expressed as a complicating
factor, grief, questions), and/or are brittle, notoriously hard to get
right, document, or understand.  We also have statements from a Drupal
developer and from the Dublin Core community to the contrary, as well
as a number of statements that namespaces are simple and easy to learn,
and that the use of prefixes makes markup easier to read and
understand.  We also have a statement that simplicity in this case, is
not having to remember a slew of difficult to remember URLs.  Finally,
a number of other "indirection" meta data models were identified.

Clearly both sides feel strongly about this issue.

In all, we found we had to agree with the following statements:

   none of the links above actually provide any sort of hard data as to
   whether or not prefixes are effective in RDFa and readers should not
   consider them, just as they should not consider the anecdotal
   evidence provided by the counter proposal.  There is currently no
   scientific study that demonstrates that prefixes are difficult to use
   for authors writing RDFa.

The operative question here isn't whether the arguments on either side
for simplicity cancel out or if, in fact, one side is stronger than the
other, but rather one of whether ANY of these arguments are stronger
than the evidence that RDFa usage is growing, and that the proposed
change would break existing content.  Lacking any specific evidence
that the specific change proposed to remove the prefix features from
RDFa would have a direct and positive impact on the adoption rate of
this technology, we find any and all arguments based on "simplicity" to
be weaker than the arguments of "breaks existing content".

=== Other Objections

We then evaluated a number of other objections found.  Each are quoted
and then assessed below.

   Arbitrary prefixes in dynamically changing content (like HTML) are
   even worse

This is an argument in behalf of others, and the example itself is
artificial.  Given the amount of deployment that RDFa has to date, if
this was a big problem it should be easy to identify a significant
number of specific cases where this was a problem.  Lacking such
evidence, this objection was found to be weak.

   never actually solved a problem for me

On one hand, this is the type of first person arguments that we wish to
encourage.  On the other hand, one can never disprove a negative using
any number of observations.  Given the cited growth rates, the burden
of proof is on anybody that asserts that RDFa prefixes don't solve a
problem for anybody.  As such we found this objection to be weak.

   I object to using very recent legacy as a rationale for backward
   compatibility

This goes to the heart of the matter, but instead of arguing that the
proposal itself is harmful, it argues that adopting it would reward bad
behavior.  In most change proposals, this would simply be listed in the
"Arguments Not Considered" section, but as it addresses the strongest
objection head on, in this decision we felt it merits addressing
along with the other objections posed.

In a response to this objection, the other Change Proposal cites
"Support Existing Content" and "Pave The Cowpaths" as design
principles.  As no evidence was cited that indicated that an approach
of "find out what syntax people are willing to deploy and standardize
that" constitutes bad behavior, nor was any evidence provided that
this working group has consensus on the principles behind this
assertion, this argument was not considered to be strong.

=== Arguments not considered:

Following are either direct quotes or paraphrases of arguments which
were put forward which were not considered.

   Running examples from the OpenGraph Protocol site through the
   facebook linter shows that removing the prefix declaration has no
   effect but changing it prevents any properties from being recognised.
   Code inspection of some of the other tools indicates that there are
   clients in Python, PHP, Ruby and Java that depend on literal matching
   of the string "og:".

No change proposal was put forward suggesting that all usages be
migrated to fixed prefixes.  Nor was there any evidence put forward
that fixes to these tools would break content.  The fact that these
tools have bugs is uncontested but that, in itself, does not help
identify the proposal that draws the weakest objections.

   Removing xmlns support ONLY would not affect RDFa content that makes
   use of profile or prefix.

Neither change proposal proposed removing xmlns support ONLY.

   something too terrible to actually use can be fixed by adding a level
   of indirection

In this case, the technology that is purportedly "too terrible to
actually use" would be URIs.  As neither Change Proposal sought to
change this, this argument was not considered.

   I object to appealing to the quantity of existing content that uses
   RDFa-looking syntax without providing statistics

As the cited specifics were not provided for either proposal, this was
not a deciding factor in choosing the proposal that attracts the
weakest objections.

   It would be important to know if Facebook's and Google's content
   consuming code could be made work with prebound prefixes for
   compatibility with legacy content that uses prefixes.

We only consider proposals which actually were put forward.  Neither
change proposal proposed standardizing Facebook's or Google's prefixes.

   At least two W3C member submissions (ccREL and Representing vCard
   Objects in RDF) document patterns for using RDFa with prefixes in
   HTML without mentioning any media type requirements.

There was an objection to this argument and it was not found to be
necessary to evaluate the merits of this assertion in order to select
the Change Proposal that drew the weakest objections.

   I object to the Change Proposal's examples proving that prefixes
   aren't complicated

We are looking for objections to proposals, not to rationales; that
being said, the examples in question were not used to evaluate the
strength of the objection.

   I object to making something optional being an acceptable to address
   claims of the harmfulness of the feature

No such statement was used to evaluate the strength of the objections
presented.  To the contrary, the assertion was made that prefixes are
useful and popular.

   I will file a Formal Objection

A preemptive statement that a Formal Objection will be filed against a
decision that has not been written much less evaluated could be
considered as participation in bad faith.  We strongly discourage such
statements from being made in future surveys.  In its place, we
encourage people to identify objections that they themselves feel to be
strong, and to back up such statements with evidence.

*** Decision of the Working Group ***

Therefore, the HTML Working Group hereby adopts the "Clarify how
prefixes work in RDFa, and that they're an optional feature." Change
Proposal for ISSUE-120.  Of the Change Proposals before us, this one
has drawn the weaker objections.

== Next Steps ==

Bug 7670 is to be CLOSED and marked as WGDecision.  ISSUE-120 is also
to be marked as CLOSED.

Since the prevailing Change Proposal does not call for a spec change, no
further action is required.

== 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.  An example of
possible relevant new information:

* Evidence that a substantial majority of the existing producers of
   content which includes RDFa have migrated to using prefixless markup
   coupled with a number of first hand statements from implementers of
   RDFa consuming tools or toolkits (as opposed to implementers of tools
   or toolkits that consume arguably related content) that eliminating
   the need to support prefixes would produce a significant reduction in
   either maintenance or support costs.

Received on Tuesday, 29 March 2011 14:59:52 UTC