Re: Review of latest RDFa Core 1.1

Thanks Shane ...

On Mar 5, 2011, at 6:18 PM, Shane McCarron wrote:

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.

I guess what concerns me is the requirements of a conforming processor. This depends on the interpretation of the third sentence (If the RDFa Processor is unable ...). I would hope/expect that a processor which uses unspecified heuristics to determine the document type (e.g., file extension, root element name, etc.) would not be inconsistent with this definition. If this leaves room for other forms of identification, perhaps the spec should explicitly permit this.

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 ;-)

Yes, I see that a prefix must match the NCName production, which precludes the empty string. I'll add a test for @prefix and @profile to insure that these do not result in a change of the default prefix.

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<mailto:shane@aptest.com>