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

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.

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

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

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


-- 
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 14:22:49 UTC