Re: Review of latest RDFa Core 1.1

Gregg,

Thanks for your comments.  My replies are inline:

On 3/5/2011 3:05 PM, Gregg Kellogg wrote:
> I've been doing my own review and updating my processor at the same time. Here are some of my notes:
>
> Notes on review of 3/1 Editors Draft of RDFa Core 1.1: http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview.html.
>
> Section 4.1 RDFa Processor Conformance
>
> Here it states that the processor *must* examine the media type and process the document as application/xml if it is unable to determine the media type. However, there is no description of how the processor should make this determination. Presumably, for a document retrieved over HTTP, the media type can be determined by examining the Content-Type header to determine this. However, what about documents not retrieved via a medium which reports Content-Type? For example, can a file extension be used to determine the media type of a file on a local file system (e.g., .html, .xhtml, .svg, etc.). I don't see that IANA defines associated file extensions for media types.
>
> Is it acceptable to examine the root element name to determine the document type?
>
> This section requires some clarification.

The working group debated this, and decided that it was impossible to 
specify anything beyond media type.  I personally agree that the DOCTYPE 
is a fine way to announce the type of a document (hence the name).  But 
this sort of 'sniffing' seemed beyond the will of the working group. For 
similar reasons, defining specific suffixes is something that is 
certainly not going to happen.

Personally, I would be open to changing the text to read like the following:

    A conforming RDFa Processor /must/ examine the media type of a
    document it is processing to determine the document's Host
    Language._If the media type is unavailable, a conforming RDFa
    Processor MAY look at the document's DOCTYPE to determine if its
    Formal Public Identifier matches that of a known Host Language. _ If
    the RDFa Processor is unable to determine the document's Host
    Language, or does not support the Host Language, the RDFa Processor
    /must/ process the document as if it were media type
    |application/xml|. See XML+RDFa Document Conformance
    <http://www.w3.org/2010/02/rdfa/sources/rdfa-core/Overview-src.html#xmlrdfaconformance>.

However, note that the text above PRECLUDES the HTML5-style doctype with 
no FPI.  There might be a way to encompass that in this clause... but I 
personally feel that the absence of an FPI really can't be taken as 
announcement that a document is written in a specific Host Language.

> Section 6. CURIE Syntax Definition
>
> Paragraph 3 describes the 'default prefix' mapping to be http://www.w3.org/1999/xhtml/vocab#. To me, this implies that the initial list of URI mappings (described in 7.5) contains such a mapping, however the text explicitly states that it is empty (or as defined in the RDFa Profile). Indeed, the XML RDFa Profile does contain this mapping, but what about host languages that don't use this profile? 4.3 XML+RDFa Document Conformance only applies to generic XML documents, and is integrated into XHTML+RDFa 1.1. Presumably, a host language could not include this definition, or any default profile. Should the language indicate that the initial set of uri mappings include XHV?

The default prefix mapping is very special.   It is the mapping that 
comes into play with there is a colon and a reference (e.g., :prev).  It 
is not possible to override this mapping.  All RDFa processors are 
required to support it.  The term 'default prefix' is unfortunate, but 
is historical and I don't feel like we can change it at this time.

So, to answer your question, no - I don't think that there is any need 
to define this mapping in the RDFa Profile.  Indeed, I don't think there 
is any WAY to define it.  And if there is, I think that is an error.  
Since this is not meant to be overridable, there shouldn't be a way to 
define the mapping.  That way lies madness ;-)


> Otherwise, I think the changes make the document more accessible to people from outside the community. Good work.

Thanks!

> Gregg
>

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