W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > January 2013

Official Response to ISSUE-143 (Prefixes too complicated) from RDFa WG

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sat, 19 Jan 2013 14:33:10 -0500
Message-ID: <50FAF4F6.2030000@digitalbazaar.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: RDFa WG <public-rdfa-wg@w3.org>
Hi Tab,

Thank you for your feedback on the RDFa 1.1 specifications. This is
an official response from the RDFa WG to your Formal Objection before we
enter the Last Call phase for the RDFa 1.1 specifications. Thank you for
sending in this issue before the Last Call deadline, it made it easier
for us to make multiple attempts at resolving the issue.

The issue leading to your Formal Objection was tracked here:


The Formal Objection was transferred to this group and tracked here:


Explanation of Issue

You were concerned that the use of a prefix mechanism in RDFa is too
complicated. Specifically, you were concerned that a mechanism that can
be bound to arbitrary strings then combined with other strings to form a
third set of strings are too complicated for a general-purpose Web

You proposed two potential solutions:

1) Disallow overriding prefixes defined in the RDFa initial context.
2) Remove the prefix mechanism in RDFa.

Working Group Decision

The HTML WG had previously discussed the issue and resolved to not
remove the feature:


Specifically, this was a formal HTML WG decision:


You raised a Formal Objection after the decision was rendered:


The HTML WG post-poned the issue:


and then transferred the issue and the Formal Objection to this WG:


As you know, the prefix mechanism in RDFa has a very long, documented
history. It was introduced in XHTML+RDFa 1.0 via 'xmlns:' and then
modified in RDFa 1.1 to use the 'prefix' attribute. The general goal of
the mechanism has not changed in that time. The reason it exists is to
provide decentralized extensibility for authors and enable easy
vocabulary mixing for documents.

The RDFa WG discussed your proposals on two occasions:



The group was very concerned that removing the prefix mechanism in RDFa
would cause authors far more harm and confusion than it would help.
Removing such a feature would be a backwards-incompatible change.
Removing the feature could only be done in HTML+RDFa 1.1 and not RDFa
Core 1.1, XML+RDFa 1.1, RDFa Lite 1.1, and XHTML+RDFa 1.1 since all of
the other specifications are RECs at this point. This group is not
chartered to modify those documents. Removing the feature would cause
fragmentation among the RDFa specifications. In short, the Working Group
felt that removing the prefix mechanism from the HTML+RDFa 1.1
specification would be short-sighted and removing it from all RDFa
specifications would be a long-term disaster for authors, implementers,
and the RDFa language.

RESOLVED: Keep the prefix-indirection mechanism in HTML5+RDFa 1.1.


The proposal to disallow overriding prefixes defined in the RDFa initial
context was the most workable proposal to date and enjoyed considerable
discussion. The major concern with the proposal was that if an author
were to use a prefix 'foo' today, and then in the future a new prefix
'foo' was introduced to the initial context, that all previous documents
that used 'foo' would become broken because they would all point to the
wrong IRI. This would either mean that any update to the RDFa initial
context would risk destroying information on the Web. This risk was
unacceptable to the group.

RESOLVED: Allow prefixes specified in the RDFa initial context to be
overridden using the prefix-indirection mechanism HTML5+RDFa 1.1.


The biggest general concern, however, were not the proposals that you
put forward. It was that there is no data to backup the base claim that
you are making: That the prefix mechanism is causing an unacceptable
number of authoring and implementation mistakes in the wild. We had
asked you to provide this data on two occasions and received no response
to either request:



Every time this issue is raised, the Working Group asks for data
demonstrating this issue. In the last 6 years, I am unaware of any such
data being presented to the Working Group. If this was as big of an
issue as you are claiming, we'd expect to see more readily available
data or research on the topic.

As a result of your Formal Objection, the Working Group did implement a
change to the HTML+RDFa 1.1 specification that we expect to be generally
implemented in all RDFa 1.1 processors:

RESOLVED: Generate a warning in the processor graph when a prefix
declared in the RDFa initial context is overridden with an IRI that is
different from the IRI specified in the RDFa Initial Context.


The RDFa WG believes that this warning, as long as it is exposed to
authors, will help authors know when they are redefining an IRI. It was
later agreed to by implementers to raise this warning any time a prefix
is overwritten by a different value. This feature is added to the
previous list of mechanisms intended to ensure that authors express the
data that they intend to express:

1) If the author forgets to declare the prefix, common prefixes are
pre-declared via the RDFa Initial context.
2) If a prefix is used that does not have a mapping, most RDFa
processors will report a warning that a prefix that should have been
defined is probably not defined.
3) If an author overrides a prefix with a different value, including
prefixes declared in the RDFa Initial Context, a warning will be
generated to notify them of the potential issue.

While we understand that these protections probably do not resolve the
underlying issue that you have with RDFa prefixes, we hope that we have
demonstrated that we have listened and added features to alleviate some
of the concerns around this issue. In the end, both of your proposals
were rejected because compelling evidence was not provided to support
your base claim, and because all proposals for removing or modifying the
feature would break documents in the past or make migrating to new
prefixes impossible in the future.


Since this is an official Working Group response to your Formal
Objection, and since the group is under an extremely tight deadline, we
would really appreciate it if you responded immediately to this e-mail
and let us know if the findings and decision made by the group is
acceptable to you as soon as possible. If you still wish to pursue your
Formal Objection with the Director, please make that clear in your
response to the group.

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The Problem with RDF and Nuclear Power
Received on Saturday, 19 January 2013 19:33:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:33 UTC