W3C

Site Navigation

Nearby

Results of Questionnaire ISSUE-120: Use of prefixes is too complicated for a Web technology - Straw Poll for Objections

The results of this questionnaire are available to anybody.

This questionnaire was open from 2011-03-10 to 2011-03-17.

10 answers have been received.

Jump to results for question:

  1. Objections to the Change Proposal to simplify the RDFa-in-HTML specification by removing features that are documented to be confusing to users
  2. Objections to the Change Proposal to clarify how prefixes work in RDFa, and that they're an optional feature.

1. Objections to the Change Proposal to simplify the RDFa-in-HTML specification by removing features that are documented to be confusing to users

We have a Change Proposal to simplify the RDFa-in-HTML specification by removing features that are documented to be confusing to users. If you have strong objections to adopting this Change Proposal, please state your objections below.

Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.

Details

Responder Objections to the Change Proposal to simplify the RDFa-in-HTML specification by removing features that are documented to be confusing to users
Manu Sporny I have a very strong objection to this change proposal - I will file a Formal Objection in the case that the prefixing mechanism is removed (due to the awful usability/technical issues it creates). The RDFa Working Group has a very strong objection to this change proposal - it will most likely raise a Formal Objection in the case that the prefixing mechanism is removed. This proposal would result in a massive incompatibility between how RDFa works in all other languages and how RDFa works in HTML5. The change would be non-deterministic and would go /against/ the massive amount of usage data collected thus far. This is an awful "fix" for a problem that doesn't exist as demonstrated by the large amount of real-world usage data in the counter-proposal.

I should also point out that xmlns: /only/ exists in HTML5 for backwards compatibility reasons, it is deprecated, HTML5 authors should not use it. Leif's comments are made on the basis of the current Working Draft of HTML+RDFa, not on the current resolutions made (as of two weeks ago) in the RDFa WG to deprecate xmlns: in all RDFa languages.
Ben Adida Yahoo published, only weeks ago, data showing that 3.6% of the web uses non-trivial RDFa, meaning RDFa with namespaced values:

http://tripletalk.wordpress.com/2011/01/25/rdfa-deployment-across-the-web/

That's more than 500% year-over-year growth. Compared to the anecdotal evidence presented in this change proposal, the facts speak fairly clearly: prefixes are not causing a deployment problem.

Worse, if this change proposal were taken into account by implementers, they would suddenly lose the ability to parse RDFa present on 3.6% of the Web. What is the reasonable argument for this significant damage to deployed content?

Based on this (a) the facts speak against the claims of this proposal, and (b) significant damage would result, Creative Commons will raise a Formal Objection to this proposal if it continues.
Leif Halvard Silli
I object to this probosal, because:

1) The CP suggests changes to RDFa 1.1 Core. This seems out of scope for this WG to make decisions on.

2) RDFa-in-HTML for the most part equals XHTML+RDFa which typically is served as text/html and not as application/xhtml+xml. Thus, it is not going to work to try to keep text/html as a simpler variant of RDFa. At best - or worst - this proposal could result in authors preferring XHTML+RDfa doctypes instead of using a HTML5 doctype. In fact, that this CP seeks to change RDFa 1.1 Core itself means that it admits that a limited change to RDFa-in-HTML, would be without much effect.

3) Several other "indirection" meta data models are already in use on the Web:
* (External) CSS.
* XML namespaces
* Microformats (MAY use @profile)
* Dublin Core (<head profile=*>,<link rel=schema.DCTERMS href=*> ...)
To get the indirection to "click", observeable effects are more important the complication aspect. E.g. CSS errors and effect are much tested, has visual effects and are thus quickly discovered. Likewise, xmlns in XML works well enough, it is in the text/html domain, were it is without effect, that it contains errors. For RDFa, failing to link to the external resource could lead to: a) the RDFa tagging having no effect in the document at hand b) that common values get de-facto hardwired semantics in consumers. The latter is a problem for RDFa itself - it can probably be solved defining default profiles, which I understand that RDFa 1.1 is starting to do.
Julian Reschke I disagree with the claim that prefix-based indirection inherently is confusing; on the contrary, it's widely used in other formats, and people seem to deal with it. In particular, HTML authors apparently *can* deal with the indirection mechanism used for CSS which is much more complicated.

Furthermore, removing the existing mechanism will break existing content for no good reason.
Henri Sivonen
Philippe Le Hegaret 1. The arguments against the indirect URI specification mechanism are not technical (with the exception of the @xmlns attribute, see below), but rather based on perception of a few individuals cited in the change proposal. This fails to take into account the large communities that already use, and are in favour, of similar mechanisms; some of these are documented in the other change proposal. We also believe that the new technical features of RDFa 1.1 (usage of profiles, default or otherwise, of default vocabularies, etc) will significantly alleviate the problems for HTML authors who may have difficulties adopting a prefix based mechanism, and there is no need to generally disallowing their usage.

The usage of the @xmlns attribute is indeed different insofar as its proper handling may create technical problems in HTML not serialized in XML. However, we feel that the RDFa Working Group has taken the appropriate measures by deprecating this attribute in favour of @prefix that does not suffer from this problem.

2. There has been a significant uptake of RDFa in the past years, as shown in the other change proposal. As an additional information (that became public since starting this poll) let us refer to a recent decision of the International Press and Telecommunication Council (IPTC) to go ahead with a deployment plan (put forward by the New York Times) to mark up news items in future using RDFa. We have seen that as different communities get experience with RDFa then usage skyrockets (cf. the 3.6% and >500% mentioned in the other no-change proposal). With news organizations on board, the growth momentum has another tangible reason to continue. Adopting the change proposal would significantly harm current deployment, would make a large number of Web pages unnecessarily invalid, and would also break the synergy between Web based Applications and application making use of the flourishing world of Linked Open Data, Open Government data, Semantic Web, etc.

3. Adopting the change proposal for HTML5 would mean a huge discrepancy between the usage of RDFa in HTML5 and in other languages as defined by the RDFa Working Group. RDFa 1.1 is also defined for a generic XML; that includes SVG (that already refers to RDFa as a possible vehicle to add metadata to an SVG file), ODF (that has already adopted RDFa based on its XHTML format), ATOM, or indeed any type of XML data, proprietary or otherwise. Creating such incompatibility would create major problems for tool developers, and create problems for authors who would use both HTML5 and XML based data in conjunction with RDFa.
James Graham
Andreas Kuckartz The use of prefixes makes it easier to read and understand RDFa-in-HTML code.
Toby Inkster Most of my arguments against this proposal are best summed up in my counter-proposal, as the dividing line between arguments *against* this, and arguments *for* mine is slim.

In summary though: this proposal is based on the presumption that the use of prefixes is too difficult and unfamiliar for the majority or at least a large proportion of users. However the evidence for this claim is virtual non-existent: some anecdotal stories about people having trouble using XML namespaces (which are a related but not identical technology to CURIEs), and a small informal usability study conducted on, as I understand it, only six people.

Based on this dubitable evidence, the proposal suggests a change in HTML+RDFa that would throw out compatibility with existing RDFa content, with the XHTML+RDFa 1.0 Recommendation and with the draft XHTML+RDFa 1.1 specification.

I object to this proposal.
Kang-Hao (Kenny) Lu I have only a weak objection to a claim in the rationale but strong
objects to the "positive effects" section and the proposed change as it
is, since I find it hard to believe that doing the proposed change would
actually "let more people use it" as advised and making this change has
too many undesirable side effects.

I (weakly) object to the claim that arbitrary prefix mechanisms are unnecessary.
Assuming there's consensus that adding machine-readable annotations/data
will make the Web better, the prefix mechanism is an important syntactic
sugar that will encourage authors to put more machine-readable
annotations/data on the Web. It also improves the readability of this
format. In fact, I would encourage the working group to come up with a
syntactic sugar for shortening property URL in Microdata.

I appreciate the effort to make the specification reflect implementation
reality. However, although Google's RDFa implementers chose to deviate
from standard, it's hard to believe that they would really like to see
the proposed change happen as then they will need to revise their
instruction pages (from <span property="v:region"> to <span
property="http://rdf.data-vocabulary.org/#region"> and so on) and change
their implementation in an incompatible way. If advocates of this
proposal really want to remove xmlns="", prefix="" and etc., a mechanism
of unversioned/dynamic profile of prefix mapping seems better (and hence
the prefix is not rebindable) and should be proposed. It has to be
unversioned/dynamic as there are likely to be new vocabularies deployed
in the future. (Notice that a year ago there was no og:, and media: used
by Google's video search[1] is still not in the existing RDFa core
default profile[2]).

If the second bullet point in the details section is adopted, legacy content
will be parsed into triples with predicate like "media:thumbnail"
as absolute URLs, and this is not acceptable.

I agree that prefix isn't easy, but I disagree with the claim[3] that
every feature in HTML5 is for "broad Web deployment". For example, you
need certain linguistic knowledge[4] to tell <em> and <strong> apart so
that you can use them as semantic tags. Perhaps the situation here is
similar.

[1] http://www.google.com/support/webmasters/bin/answer.py?answer=162163
[2] http://www.w3.org/profile/rdfa-1.1
[3] http://www.w3.org/Bugs/Public/show_bug.cgi?id=7670#c11
[4] http://www.cs.tut.fi/~jkorpela/html/em.html

2. Objections to the Change Proposal to clarify how prefixes work in RDFa, and that they're an optional feature.

We have a Change Proposal to clarify how prefixes work in RDFa, and that they're an optional feature.

Keep in mind, you must actually state an objection, not merely cite someone else. If you feel that your objection has already been adequately addressed by someone else, then it is not necessary to repeat it.

Details

Responder Objections to the Change Proposal to clarify how prefixes work in RDFa, and that they're an optional feature.
Manu Sporny No objections to this Change Proposal. The RDFa Working Group also reviewed and endorses this change proposal - to clarify how prefixes work in RDFa. If authors don't like the prefixing mechanism, they don't have to use it.

I should also point out that xmlns: /only/ exists in HTML5 for backwards compatibility reasons, it is deprecated, HTML5 authors should not use it. Leif's comments are made on the basis of the current Working Draft of HTML+RDFa, not on the current resolutions made (as of two weeks ago) in the RDFa WG to deprecate xmlns: in all RDFa languages.
Ben Adida
Leif Halvard Silli I have an objection to *one part* of this proposal: I am sceptical to the idea to permit the xmlns prefix because:

1) it is only a compatibility feature - RDFa 1.1. don't need it, as RDFa 1.1 Core says:
]] Mappings are defined via @prefix. For backward compatibility, some Host Languages may also permit the definition of mappings via @xmlns.[[

2) there are no current versions of HTML5 "in the wild" which permits any other xmlns values than those which HTML5 explicitly permits. Probably very few of the 430 million XHTML+RDFa pages which uses xmlns does thus claim to be HTML5 pages and if some of them claim to be HTML5, then HTML5 isn't ready yet etc.

3) I don't think that to keep xmlns="*" will simplify the task of clarifying how the prefixes work. Better to make a clean cut and not permit xmlns, from the start, so that there is only "one true way" to do it, in HTML5.

4) The xmlns is used in a untypical way: it declares namespaces, but doesn't really make any use of them.

5) This would not affect RDFa parsers - I believe they would be free to accept such illegal xmlns declarations

6) If xmlns were forbidden in HTML+RDFa, then it is likely that it would have become a push which would causes more and more authors to stop useing xmlns, even in XHTML+RDFa. Which sounds like a bonus, given that @prefix is the preferred way.

It is somewhat surprising that the RDFa-in-HTML spec only shows @xmlns examples (that is: there are no @prefix examples). And, actually, very little is said about the use of @prefix. If this is all that needs to be said about @prefix, then it does indeed seem like removing @xmlns from HTML+RDfa would simplify a good deal.
Julian Reschke
Henri Sivonen I object to using very recent legacy as a rationale for backward compatibility when the legacy has been developed during this ISSUE remaining known (even before it was formally raised as one) and unresolved. The entire legacy has arisen during a time when RDFa officially hasn't existed for text/html but the RDFa community has condoned and celebrated deployment as text/html even though the 1.0 was put through the W3C Process in such a way that it was reviewed as an XML spec. Moreover, text/html-related syntax concerns were raised before 1.0 went to REC, but HTML-oriented engagement on the topic seems was deferred in order to get the XHTML side to REC anyway. See http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-August/015913.html from an editor of that spec : "I didn't mean to start this thread just yet (we're in the middle of our transition to Proposed Rec at W3C for RDFa in XHTML 1.1)"

If the recently-created legacy is treated as a strong rationale, it would effectively encourage any other participant wishing to push a feature to engage in legacy creation ahead of addressing concerns identified by broader review.

I object to appealing to the quantity of existing content that uses RDFa-looking syntax without providing statistics about how often that content is a) not actually consumed by anything, b) consumed by tools that do not implement the RDFa algorithms and the RDF graph model but just use the syntax in simpler scraping in order dress up something simpler and product-specifi as W3C-ish looking and c) is actually processed using the RDFa algorithms and using the RDF graph model.

Processing of the type c) would be the most affected by supposedly backwards-incompatible changes, so that's what should be quantified instead of content out there that uses restricted RDFa-looking syntax to integrate with e.g. Facebook or subfeatures of Google Search.

I object to appealing to Facebook's or Google's encouragements without showing evidence that Facebook or Google actually implement RDFa algorithms and the RDF data model as opposed to using parts of RDFa-looking syntax in different processing (as has been suggested in http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2009Sep/0126.html ). 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.

I object to appealing to the lack of media type requirements in ccREL and Representing vCard Objects in RDF when those specs are supposedly layered on top of a spec that was put through the W3C Process as an XHTML-only (i.e. supposedly non-text/html) spec.

The London Gazette is cited as a success, but upon inspection, its use of RDFa-looking syntax in extremely shallow. On most Notices in the Gazette, only the publication date has been annotated using prefix-based RDFa syntax even though the pages appear to declare a more impressive number of prefix mappings. I object to treating London Gazette as evidence of wide deployement.

I object to the Change Proposal's examples proving that prefixes aren't complicated. On the contrary, the examples prove prefixes are hard to use. Upon inspection, one of the provided examples (the second one I bothered to inspect after London Gazette), http://stores.bestbuy.com/1895/, uses several property attributes whose value starts with the prefix skos: without the prefix having been declared using any proposed declaration mechanism.

I object to making something optional being an acceptable to address claims of the harmfulness of the feature. When features are hammered through a standards process by saying they are merely optional, implementations still come under pressure to implement them. (For example, processing the external DTD subset is optional in XML, but there's a rather vocal even if small group of people who as for external DTD processing to be included in Firefox even though the feature was made optional because the definers of XML didn't consider it appropriate for browsers!) As for the cognitive load to authors, it's generally hard for authors to avoid the cognitive load of optional features if people they collaborate with use them or if teaching materials include mentions of them "for completeness". Thus, making a feature optional is an entirely unsatisfactory remedy to the issue of a bad feature.
Philippe Le Hegaret
James Graham This change proposal claims that "Dropping prefixes will break
existing content", based mainly on the fact that some content has been
identified as RDFa and some RDFa consuming tools exist. Some research
suggests that it is more likely that using the prefix binding
mechanism in the intended way will break consumers.

The change proposal cites some research indicating that 3.5% of
websites in the Yahoo index use RDFa. The cited blog post does not
discuss methodology in sufficient depth to determine how a page was
determined to be using RDFa. In particular it does not make it clear
whether only content with an appropriate prefix binding in scope was
considered, or whether all instances of RDFa-specific attributes were
considered.

Since Yahoo has recently dropped its RDFa-consuming SearchMonkey
product, it seems reasonable to assume that most of the growth in RDFa
usage is due to Facebook and Google adding some features that depend
on RDFa. For simplicity I have looked at the facebook support for
prefixes.

The OpenGraph Protocol site [1] has examples that declare the "og"
prefix in the HTML element. It also contains a list of tools to
consume such markup. To test the behavior of these tools, I created
two example pages based on the "good" sample from the facebook linter
[2]; one with no xmlns prefix declaration [3] and one with the prefix
declared but as "opengraph" rather than "og".

Running these pages through the facebook linter shows that removing
the prefix declaration has no effect [5] but changing it prevents any
properties from being recognised [6].

Code inspection of some of the other tools indicates that there are
clients in Python [7] PHP [8], Ruby [9] and Java [10] that depend on
literal matching of the string "og:". It appears that there are also
clients in PHP [11] and Perl [12] that use RDFa libraries and so,
presumably, do real RDFa parsing. I note for future reference that
these latter tools appear to have been developed by the one individual
who is heavily involved in the RDFa community.

I conclude that the assertion that "dropping prefixes will break
existing content" is not supported by the example of facebook. In fact
I think this example shows that /using/ prefixes in a meaningful way
will break content; if one wants interoperability one *must* use the
string "og:" as the "prefix". This appears to be considerably more
important than declaring the "prefix" anywhere; the majority of the
tools examined would not fail if the "prefix" was out of scope. In
effect the OpenGraph protocol is consumed as a number of unprefixed
property names that start with the string "og:".

This conclusion also bears on the second assertion in the change
proposal "RDFa with prefixes is not especially complicated". Since the
only consumers tested that used RDFa prefixes as intended were written
by members of the RDFa community, it seems likely that either a) using
prefixes in the intended way was too hard for the authors of the other
consumers or b) they believed that writing clients that conformed to
the RDFa specification would cause their tool to process less content
than otherwise, implying that they believe a significant amount of
non-compliant content will exist. In either case it is clear that
there is a constituency for whom a prefix-free format is managable,
but a format that requires prefixes is not.

[1] http://ogp.me/
[2] http://developers.facebook.com/tools/lint/examples/good
[3] http://hoppipolla.co.uk/410/rdfa.html
[4] http://hoppipolla.co.uk/410/rdfa-1.html
[5] http://developers.facebook.com/tools/lint/?url=http%3A%2F%2Fhoppipolla.co.uk%2F410%2Frdfa.html
[6] http://developers.facebook.com/tools/lint/?url=http%3A%2F%2Fhoppipolla.co.uk%2F410%2Frdfa-1.html
[7] https://github.com/minichiello/PyOpenGraph/blob/master/PyOpenGraph/PyOpenGraph.py
[8] https://github.com/scottmac/opengraph/blob/master/OpenGraph.php
[9] https://github.com/intridea/opengraph/blob/master/lib/opengraph.rb
[10] https://github.com/callumj/opengraph-java/blob/master/src/opengraph/OpenGraph.java
[11] http://buzzword.org.uk/2010/opengraph/#php
[12] http://search.cpan.org/~tobyink/RDF-RDFa-Parser/lib/RDF/RDFa/Parser.pm
Andreas Kuckartz
Toby Inkster No objections obviously.
Kang-Hao (Kenny) Lu I have no objections to the proposed change.

But I object to using non-conforming content (such as og: content
without prefix declaration) or implementation in the rationale and I
would suggest the RDFa working group and/or the newly created RDF
working group do their best to correct misimplementations non-conforming
to the specifications. At least they should keep a list of conforming
and non-conforming agents as James Graham did. They should also do their
best to correct non-conforming documents if ever possible.

More details on responses

  • Manu Sporny: last responded on 14, March 2011 at 01:32 (UTC)
  • Ben Adida: last responded on 14, March 2011 at 01:58 (UTC)
  • Leif Halvard Silli: last responded on 16, March 2011 at 12:33 (UTC)
  • Julian Reschke: last responded on 16, March 2011 at 13:37 (UTC)
  • Henri Sivonen: last responded on 17, March 2011 at 10:32 (UTC)
  • Philippe Le Hegaret: last responded on 17, March 2011 at 12:05 (UTC)
  • James Graham: last responded on 17, March 2011 at 12:12 (UTC)
  • Andreas Kuckartz: last responded on 17, March 2011 at 21:17 (UTC)
  • Toby Inkster: last responded on 17, March 2011 at 22:44 (UTC)
  • Kang-Hao (Kenny) Lu: last responded on 18, March 2011 at 02:06 (UTC)

Everybody has responded to this questionnaire.

Compact view of the results / list of email addresses of the responders

WBS home / Questionnaires / WG questionnaires / Answer this questionnaire

Report issues on GitHub project w3c/wbs-design or by mail to sysreq.