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

On Jan 21, 2011, at 15:22 , Shane McCarron wrote:

> 
> 
> On 1/21/2011 2:32 AM, Ivan Herman wrote:
>>> 
>>> 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.
> 
> Actually... I disagree.  I think we could specify that it was application/xml and text/xml.  Those are the reserved.  We could also say that a conforming processor SHOULD treat other +xml media types as RDFa+XML if the processor does not support that host language.  We cannot say anything about defined host languages - there will be more and more of these over time, and the introduction of the ePub Host Language cannot, for example, push a processor out of conformance.

Damn, I thought we would _really_ disagree this time:-)

You are right, the way you formulate the +xml types is obviously the way to go.

(I did not even realize that text/xml is used...)

> 
>> 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.
> 
> I think that when a processor treats a document as RDFa+XML the profile for that host language should be used.  Otherwise, the profile (or lack thereof) for the associated host language should be used.  Otherwise, if I introduce RDFa+Shane, and that has no profile at all, I will still get one EVEN when a processor knows about my host language.  That's not cool.

I am not really sure I understand. Let us suppose my processor knows about the host languages (and profiles) for application/xml, text/html and application/xhtml+xml.

- If I get an application/shane+xml, then the profile for XML+RDFa applies, defined for application/xml
- If I get an application/xhtml+xml, then the profile for XML+RDFa plus the profile for XHTML+RDFa applies. (There may be redundancy, but that does not harm)
- If I get a text/shane, then no profile applies

I am not sure what the problem is with this. If you define shane as being an xml, then there is no surprise if you get an xml profile content...

> 
>> 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...
> 
> My text says 'would likely *not* define as many 'TERMS' as are defined in...'.  

Ouch, I have to change my glasses...

> I agree with you - most of those terms are (X)HTML related.  Some of them might be generic.  Like license.  We should go through them.

Indeed. Actually, the only one I have put into the generic one on the wiki page, and that was describedby. And because all the other terms are defined in the xhtml namespace, I wonder whether we should not keep it that way (although, I agree, some of these have a more general 'semantics'...)

> 
>>> 
>>> 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.
> 
> See my comments above.


Meaning in this case, that other host languages must not use text/xml or application/xml, right?

Ivan

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