Re: Last Call Response to ISSUE-73: RDFa Profile management

Well... we have no requirement that all host language default profiles 
are a superset of the RDFa+XML default profile.  And indeed I can easily 
imagine a host language (ShameML) where I do not want terms defined in 
that profile.  Or I do not want prefixes defined in that profile.  Why 
would we have such a requirement?

Second, even if we DID have such a requirement, it would certainly be 
more efficient to just require that the data be included in the profiles 
than to have each language processor read / process two profiles every 
time they parse a document.  Wouldn't it?

On 2/28/2011 12:02 AM, Ivan Herman wrote:
> Shane,
>
> I may not understand what you say. But if I do, this is not a minor 
> issue. Indeed, the question is whether the core default profile is a 
> subset of the xhtml default profile or not. Put it another way, 
> whether all the prefixes and terms defined in the core profile should 
> be repeated in the xhtml profile, too. Manu's approach means that it 
> is unnecessary to do so, in your case it is. I happen to be on Manu's 
> side on this although, as we say, I would not lie down the road...
>
> Ivan
>
> ----
> Ivan Herman
> Tel:+31 641044153
> http://www.ivan-herman.net
>
>
>
> On 28 Feb 2011, at 00:47, Shane McCarron <shane@aptest.com 
> <mailto:shane@aptest.com>> wrote:
>
>> Manu,
>>
>> A minor comment:
>>
>> On 2/20/2011 1:23 PM, Manu Sporny wrote:
>>> ...
>>> Profile Document Selection Algorithm
>>> ------------------------------------
>>>
>>> The RDFa WG discussed several algorithms for determining the correct
>>> profile to use. In the end, the simplest and most reliable mechanism
>>> seemed to be to do the following:
>>>
>>> 1. Always load the RDFa Core 1.1 default profile first.
>>> 2. If an "application/xhtml+xml" or "text/html" MIMEType is detected,
>>>     load the HTML+RDFa 1.1 default profile.
>>>
>>> Step #1 will be placed into the RDFa Core 1.1 specification. Step #2
>>> will be placed into the (X)HTML Host Language specifications.
>>
>> I actually DISAGREE with this.  I think it is more sensible to have 
>> the processor determine the media type, then act accordingly.  In 
>> fact, we had already introduced text that supports that model [1]:
>>
>>> A conforming RDFa Processor /must/ examine the media type of a 
>>> document it is processing to determine the document's Host Language. 
>>> If the RDFa Processor is unable to determine the media type, or does 
>>> not support the media type, the RDFa Processor /must/ process the 
>>> document as if it were media type |application/xml|. See XML+RDFa 
>>> Document Conformance.
>>
>> I say this is a minor comment because I believe the effect on 
>> document processing is identical - it really just means that an 
>> implementation is not required to read / process TWO default profiles 
>> in what is likely to be the most common case.  After all, I think we 
>> all expect that HTML4 / HTML5 documents are the most prevalent on the 
>> network.
>>
>>
>>
>> -- 
>> 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>
>>

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com