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

On Jan 21, 2011, at 05:46 , Shane McCarron wrote:

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

I think it is more than that; it should be

application/xml

and any variant of

application/XXX+xml

where XXX+xml does not have a separate host language defined.

Which re-raises the inheritance issue, though. I really wonder whether we should not say that the XML profile is automatically valid for all application/XXX+xml media types. It leaves the issue of text/html open, though.

Otherwise yes, I agree, we should have such section.

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

I had a separate mail on that yesterday, and I will bind it to the correct Issue(s) as part of the triage exercise. 

http://lists.w3.org/Archives/Public/public-rdfa-wg/2011Jan/0109.html

I disagree with your statement on saying that this profile would contain the terms as defined for XHTML+RDFa. Those terms are *HTML* specific and we should keep it that way. There is no reason to have a term like 'next' or 'stylesheet' for a generic XML file for which those terms are meaningless. For details see my initial draft

http://www.w3.org/2010/02/rdfa/wiki/DefaultPrefixPolicy

I agree with the rest...

> 
> 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'.

application/xml ?

Otherwise I agree.

Thanks

Ivan



> 
> [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
> 
> 
> 


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf