Re: Handling of missing @profile

I concur that it is editorial, and I will make the change now.

On 8/5/2010 12:17 PM, Manu Sporny wrote:
> On 08/03/10 22:40, Gregg Kellogg wrote:
>    
>> I'm confused about wording in the latest heartbeat draft of RDFa Core 1.1:
>>
>> Section 7.5 step 2 indicates that if /any/ referenced RDFa Profile is
>> not available, then the current element and it's children MUST NOT be
>> processed.
>>
>> Section 9 outlines steps to process profiles and indicates that if a
>> retrieval fails to continue with the next URI.
>>
>> Presuming that 7.5 step 2 is the intention, then the steps in section 9
>> would seem to be pointless, as the effect of any more processing would
>> be thrown away.
>>
>> Consider the following
>>
>> <body profile="http://im-not-here http://im-here">  ...</body>
>>
>> This would fail attempting to process the first profile, and according
>> the 7.5s2 would cause the remainder of the sub-tree to not be processed,
>> but according to section 9, the processor would go on to process the
>> second URI and continue.
>>      
> Gregg, you're correct. The current text is mis-leading. We have already
> resolved that if there is a profile de-referencing error, that the
> subtree shouldn't be processed. It was implied that fetching the rest of
> the profiles would be useless because the processor isn't going to
> process the subtree.
>
> We should make this clear in the document. I think this is an editorial
> change, Shane - do you concur, and if so, can you make the change?
>
> -- manu
>
>    

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

Received on Thursday, 5 August 2010 17:50:18 UTC