Proposal on ISSUE-72: What should we do about a generic XML+RDFa grammar?

A couple of weeks ago, Ivan raised an important point during a meeting 
that was captured in ISSUE-72 [1].  Basically, Ivan was saying that we 
needed an RDFa Core profile, and that host languages could inherit from 
this.  In the end, the meeting moved away from that basic position; 
instead leaning toward introducing the concept of generic XML+RDFa 
document conformance and a generic profile that could be used in such 
documents.

There were three questions posed: Should there be an XML+RDFa document 
conformance section in RDFa Core?  Should there be a separate RDFa 
Profile defined for such documents?  and should we define the algorithm 
for detecting what sort of document a processor is evaluating?

1. Should there be an XML+RDFa document conformance section in RDFa Core?

I believe we SHOULD introduce such a section - 4.3.  This section would 
simply indicate that all the attributes in RDFa Core may be used as 
defined, and that they are in 'no namespace'.  The section should also 
specify that the processing 'base' for XML+RDFa documents may be 
declared using xml:base.  Finally, this section should indicate the 
media type for such documents (text/xml).

2. Should there be a separate RDFa Profile defined for such documents?

Yes, there should be a separate RDFa Profile for XML+RDFa.  That profile 
would likely not define as many 'TERMS' as are defined in the XHTML+RDFa 
Profile.  It would probably define a subset of whatever prefixes we 
ultimately put in the XHTML+RDFa and HTML+RDFa profiles.  The XML+RDFa 
Profile will need a URI, and a reference from RDFa Core.  However, its 
contents will not be reflected in RDFa Core (since they are subject to 
change more often than the base specification).

3. Should we define the algorithm for detecting what sort of document a 
processor is evaluating?

Document type and version 'announcement' has always been a problem with 
RDFa (and HTML in general).  It remains a problem.  We have no reliable 
mechanism to announce to an RDFa Processor what flavor of RDFa is in use 
by a document.  We have discussed codifying an algorithm so that 
processors can behave consistently.  I feel this is a mistake.  First, 
because we cannot anticipate all of the flavors of RDFa that will ever 
exist.  Second, because any algorithm is going to rely upon mechanisms 
that we KNOW are used unevenly in the wild (e.g., media types, DOCTYPE 
declarations, @version attributes, what have you).  At the very most, I 
suggest we limit ourselves to extending section 4.1 (RDFa Processor 
Conformance) with something like:

    RDFa Host Languages may introduce refinements or extensions to the
    processing rules defined in this specification (see section 4.2).  A
    Conforming RDFa Processor that supports a Host Language MUST process
    documents that use that Host Language's defined media type(s) in the
    manner specified by the Host Language.  If the RDFa Processor does
    not support (or cannot determine) the document's Host Language, the
    RDFa Processor MAY process the document as if it is an XML+RDFa
    document (see section 4.3).

And add to section 4.2 the following:

    The Host Language MUST identify one or more Media Types that
    documents written in that Host Language will use.  Host Languages
    other than XML+RDFa MUST NOT use the media type 'text/xml'.

[1] http://www.w3.org/2010/02/rdfa/track/issues/72
[2] 
http://www.w3.org/2010/02/rdfa/sources/xhtml-rdfa/Overview-src.html#document-conformance

-- 
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, 21 January 2011 04:46:56 UTC