Draft WG response to Henri Sivonen's last call comments

DRAFT

Henri,

This is a response from the RDFa Working Group to your last call
comments on RDFa Core 1.1.

We'd like to thank you for taking the time to review the specifiication.

Your first item of feedback was regarding the use of CURIEs in RDFa.
You stated "I'm not going to elaborate on this point, because I realize
that the WG isn't going to change this." Indeed we have not; we don't
think that our current charter would allow such a change, as (except in
one particular case) it requires us to maintain backwards-compatibility
with XHTML+RDFa 1.0. Further, while we acknowledge that there is
potential confusion around CURIEs if they are not explained correctly,
most members of the RDFa working group, and most deployers of RDFa
content in the wild seem to consider the feature, on the whole, to be a
positive one.

Nevertheless, we have not ignored this point altogether, and we're
making a number of specification changes as a result.

Firstly, we're going to try to emphasise that URIs are the value space
of most RDFa attributes with CURIEs being a mere abbreviation
mechanism. This will probably involve switching the order of the
introductory RDFa examples so show full absolute URIs being used first
with CURIEs introduced later. It will also probably involve replacing
CURIEs with absolute URIs in further examples except in those cases
where we're specifically using them to illustrate the CURIE feature.

Secondly, in response to your feedback and other feedback, we're
defining a default RDFa profile that pre-defines a number of
commonly-used CURIE prefixes. This is similar to your suggestion that
"compatibility with Existing Content could be mostly achieved by
performing by hard-coding the meanings of the common prefixes used in
deployed content that purports to use RDFa"; however prefixes would
still be locally rebindable. We have not yet discussed in detail
exactly which prefixes would be covered.

We do not believe hard-coding prefixes without allowing them to be
overridden would provide backwards compatibility with existing content;
there are too many prefixes that are customarily used as abbreviations
for multiple different full URIs - "dc", "v", "og" and "geo" spring to
mind as reasonably common ones.

Lastly, we will consider providing advice for organisations wishing to
publish re-usable snippets of RDFa, encouraging them to lean towards
full, absolute URIs rather than CURIEs, to improve copy-and-pastability.

Moving on to your other feedback, you state that "it seems questionable
that formsplayer.com (site of a product that one of the Editors has a
commercial interest in) is used in an example." We agree; Mark Birbeck
writes the occasional RDFa tutorial for various online publications,
and I imagine the example was copied and pasted from one of those, so
just slipped in. It will be replaced by an example.com or similar
reference.

You state, "the Creative Commons license example in section 2.2 uses
the anti-pattern of saying 'a Creative Commons license' (instead of
saying which one of the numerous licenses) in the human-readable
prose." Again, we agree and this will be changed.

Another of your points is regarding the brittleness of external
profiles. In a hypothetical world where Youtube and Flickr both
implemented RDFa using profiles, then the brittleness of their links to
profile documents seems secondary to the brittleness of their links to
video and image files respectively. If the latter is not seen as
especially problematic, then it's not clear why the former should be.

The working group has attempted to, as much as possible, limit the harm
that is done when external profiles are unavailable by providing
normative specification text on how to behave in these cases - to
ignore triples on the element in question and any descendent elements.
It is believed that this advice will not result in parsing any
incorrect triples; just a subset of the intended ones.

Profiles are an optional feature of RDFa, and when an author is more
than averagely concerned with the longevity of their data, they are
perhaps a feature best avoided. We will consider explicitly stating
this somewhere in RDFa Core.

You state that "it seems author-hostile to require authors to specify
the datatype of e.g. date literals instead of making the datatype of a
property a characteristic of the property in the vocabulary/ontology."

This is something perhaps better addressed further up the RDF stack. We
note that an RDF working group has recently been established by the W3C.

Also on datatypes, you question the use of XML Schema datatypes in RDFa
Core's examples. With the exception of rdf:XMLLiteral, XML Schema
datatypes are the most commonly used datatypes in real RDF data in the
wild. It makes sense to use these datatypes rather than perhaps
theoretically "better" but less realisitic examples.

You described the processor graph as an "open-ended loophole of
non-interoperability". We can see your point. When we first discussed
this feature it was a contentious one with some in the RDFa working
group considering it an important feature, and others questioning its
need at all. Your comment forced us to re-examine this feature and
we've come to the decision to specify fairly tightly what must data be
placed in the processor graph (allowing for additional data to be added
as well), but make it optional for implementations to expose such a
graph at all. While this is still a loophole of non-interoperability,
we hope that it's a more finitely-sized one.

You mention that "the statement about whitespace seems to say that
authors should assume non-conforming processors". My initial reaction
was that these lines should simply be removed, but I was pointed to
<http://www.w3.org/TR/xmlschema-1/#d0e1654> which suggests that XML
processors are permitted to trim whitespace in certain circumstances.
While this shouldn't apply to XHTML, it may factor into considerations
for other RDFa host languages. We'll try to clarify this statement in
the specification, and add that link as a reference.

Related to your first point, you say "xmlns:prefix is marked as an
optional feature. Please remove the feature altogether, because
xmlns:prefix parses differently in text/html and application/xhtml+xml
which are the media types most likely to be used to transfer RDFa."
This is a feature we cannot remove due to the backwards compatibility
requirements in our charter. We do steer authors towards the prefix
attribute though.

As far as differences go between parsing it as text/html and
application/xhtml+xml, we are not aware of any RDFa implementors who
have had problems caused by this difference. A number of RDFa
implementors have built processors that operate on DOMs generated by
both HTML5 and XML parsers, with no reported difficulties.

You state that "the processing model for the case where the optional
xmlns:prefix feature is supported isn't specified". It is somewhat
covered by step 4 in the processing sequence, though I agree that it's
not nearly detailed enough. We're updating this part of the
specification.

Hopefully those updates will also address two of your other comments:
"it's weird that the prefix attribute requires a single space between
the colon following the prefix and the URI but allows multiple spaces
between the URI and the next prefix", and "if the spec contains rules
for how to extract a set of prefix to URI mappings from the prefix
attribute, the rules are hard to locate".

Your last comment was that "it's a bad idea to use xs:anyURI as part of
a definition, because the meaning on xs:anyURI has shifted over time
and, IIRC, now any string is an xs:anyURI."

RDF's use of XML Schema datatypes differs from XML's use of them - they
are not merely syntactic checks, but impart meaning to literals. Thus,
in RDF terms, there is a difference between stating a property's range
is xsd:string versus xsd:anyURI, even if they allow syntactically the
same literal values.

I'd like to thank you again on behalf of the working group for your
detailed feedback. In the cases where we could not make the changes you
suggest, I hope that you understand our reasoning, even if you don't
fully agree with it.

-- 
Toby A Inkster
<mailto:mail@tobyinkster.co.uk>
<http://tobyinkster.co.uk>

Received on Wednesday, 2 February 2011 22:24:51 UTC