Re: ISSUE-70: PROPOSED response to Jeni

I feel properly admonished - Manu says we should be sending our 
responses directly to the submitter and copying the working group if we 
have discussed and agreed the response in a call.  Which we did.  So I 
have now sent the formal response.  Sorry!

On 2/18/2011 2:06 PM, Shane McCarron wrote:
> We had a long discussion of this issue during the meeting on 17 
> February.   As a result of that discussion, I have crafted the 
> following reply.  Please let me know if there are any objections or 
> concerns.  In the absence of any negative comments, this proposed 
> response will be sent to the commenter as a formal response by the Chair.
>
> -------
> Jeni,
>
> Thanks for your detailed comment.  The working group has reviewed this 
> comment in the context of the many other last call comments we 
> received.  Our responses are provided inline:
>
>> So to the first, large, technical point: the lack of information 
>> about versioning. Having read through the RDFa Core LC WD and the 
>> XHTML+RDFa LC WD, I can't see anything that addresses versioning 
>> except for the removal of the version attribute (which was the 
>> mechanism for indicating the version of RDFa being used provided by 
>> RDFa 1.0).
>>
>> There are a number of backwards-incompatible changes in RDFa 1.1, 
>> some of which are called out in Appendix C.1 [1], such as:
>>
>> * the introduction of the prefix attribute
>> * the introduction of terms and profiles
>> * the interpretation of complex content lacking an explicit datatype 
>> as a plain literal rather than an XML literal
>>
>> As someone managing a large site that produces RDFa, the questions I 
>> need answered are:
>>
>> 1. What are the minimal steps I need to take to ensure that my RDFa 
>> 1.0 site continues to be interpreted in the same way by an RDFa 1.1 
>> processor?
>
> We will expand the text in Appendix C so that there is guidance on 
> this.  We will also add a requirement that conforming processors MUST 
> support RDFa 1.0 - style processing when presented with the @version 
> value that was specified in RDFa Syntax [1].  Consequently, there are 
> two things you can do to achieve this goal.  First, you can put 
> version="XHTML+RDFa 1.0" on the html element of the documents your 
> site delivers.  Second, you can set @datatype="rdf:XMLLiteral" 
> anywhere you actually want an XMLLiteral generated instead of a plain 
> literal, and @datatype="" anywhere you want a plain literal.  Note 
> that if you do need to reference rdf:XMLLiteral, you will of course 
> need to define the rdf CURIE prefix using xmlns:rdf.
>
>> 2. When I move to using RDFa 1.1, how do I ensure that my site is 
>> interpreted in the same way by an RDFa 1.0 processor as it is by RDFa 
>> 1.1 processors?
>
> In general, you cannot.  If you are using RDFa 1.1 features, those 
> features are not going to be available in an RDFa 1.0 processor.  
> However, if your goal is to ensure the most compatibility with 1.0 
> processors, there are some things you can do on your site.  We will 
> describe these in Appendix C as well.  Essentially, you need to avoid 
> using any RDFa 1.1 features, set datatype="rdf:XMLLiteral" if you want 
> an XMLLiteral, and datatype="" if you want a plain literal.  You will 
> also want to ONLY use TERMs that were defined in RDFa Syntax 1.0 as 
> "RESERVED WORDS" for values of @rel and @rev.  To future-proof your 
> site, you will probably also want to use @prefix and @xmlns:foo 
> everywhere:
>
> <div xmlns:foo="http://www.example.com" prefix="foo:
>    http://www.example.com"
>
>
>
>>
>> As a developer of an RDFa processor, the questions I need answered are:
>>
>> 3. Can my processor be both a conformant RDFa 1.0 processor and a 
>> conformant RDFa 1.1 processor?
>
> The short answer is "yes".  We will add text about this in the section 
> on RDFa Processor Conformance.  In addition, in order to improve the 
> story about this going forward, we will introduce another RDFa 
> attribute, @rdfa, which will can be used by documents that wish to 
> ensure their content is interpreted against a specific version of the 
> RDFa Recommendation(s).
>
> The rules such a processor must follow are:
>
>   1. If there is an @rdfa attribute on the root element of the
>      document, examine its value.  If the value maps to a defined
>      version string for RDFa, process the document according to that
>      version's rules.
>   2. If there is an @version attribute on the root element of the
>      document, and that attribute has the value "XHTML+RDFa 1.0",
>      process the document according to the rules from RDFa Syntax 1.0
>      (for backward compatibility).
>   3. Otherwise, process the document according to the rules defined in
>      this specification (RDFa Core 1.1).
>
> Note that there is no REQUIREMENT that a document use this 
> announcement mechanism.  It is just available.  In the absence of any 
> sort of announcement, the default behavior is to use the current best 
> practice as defined in the current version of RDFa.
>
>> 4. If not, what modes of processing do I have to offer in order to 
>> best enable users of the processor to correctly interpret RDFa 1.0 
>> and RDFa 1.1 web pages in the way their authors intended?
>
> See above.
>
> The working group hopes that these comments and changes will address 
> your Last Call comment.  Please respond to this mail at your earliest 
> convenience.
>
> [1] http://www.w3.org/TR/rdfa-syntax/
>

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Friday, 18 February 2011 21:16:01 UTC