W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > December 2010

ISSUE-67 (Core - Henri Sivonen): RDFa Core 1.1 LC comments from Henri Sivonen [LC Comment - RDFa Core 1.1]

From: RDFa Working Group Issue Tracker <sysbot+tracker@w3.org>
Date: Tue, 07 Dec 2010 15:25:53 +0000
To: public-rdfa-wg@w3.org
Message-Id: <E1PPzQP-0002Nv-NK@lowblow.w3.org>

ISSUE-67 (Core - Henri Sivonen): RDFa Core 1.1 LC comments from Henri Sivonen [LC Comment - RDFa Core 1.1]

http://www.w3.org/2010/02/rdfa/track/issues/67

Raised by: Manu Sporny
On product: LC Comment - RDFa Core 1.1

RDFa Core 1.1 LC comments from Henri Sivonen:

> ... you can now use RDFa and:
>> 
>> * Not use xmlns, and declare prefixes using @prefix.
>> * Not use CURIEs at all and use full URIs instead.
>> * Not have to use CURIEs at all and instead use keywords (via @profile)

As far as my previous feedback goes, the above misses largely misses the point. If prefix-based indirection is an available option or if using xmlns:foo for declaring prefixes is an available option, consuming software has to support those features. I wanted RDFa not to have CURIEs or xmlns:foo-based declarations even as an option so that software wouldn't need to support those features.

I think prefix-based indirection is bad for authors, too. Making CURIEs and xmlns:foo optional while not removing them from the language makes the language as a whole harder for authors to work with. When authors collaborate, it's hard to learn a subset of the language and pretend the rest doesn't add any cognitive load.

To be Compatible with Existing Content, RDFa 1.1 doesn't need to be backwards compatible in the sense of parsing the same triples out of any valid RDFa 1.0 input as RDFa 1.0. Instead, it needs only to produce the right triples for the content that's already out there. Thus, 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.

Other high-level comments on the RDFa Core 1.1 spec:

 * 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.
 * 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.
 * I reiterate my previous comment that prefix-based indirection confuses authors and complicates implementation. Please use absolute URLs only instead of CURIEs. I'm not going to elaborate on this point, because I realize that the WG isn't going to change this.
 * Loading prefix definitions from an external file seems to make RDFa brittle in case the external file can't be loaded. Also, blocking RDFa processing in order to do IO to fetch the prefix definitions complicates implementation.
 * (This is a general RDF problem but...) 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.
 * It seems unfortunate to use XML Schema Datatype as an example considering how much weird variability XML Schema Datatypes allow.
 * The concept of "processor graph" seems to be an open-ended loophole of non-interoperability.
 * Under 4.1 the statement about whitespace seems to say that authors should assume non-conforming processors.
 * 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.
 * The processing model for the case where the optional xmlns:prefix feature is supported isn't specified.
 * 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.
 * 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.
 * 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.
Received on Tuesday, 7 December 2010 15:25:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:50 UTC