W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > August 2010

Re: Handling of missing @profile

From: Shane McCarron <shane@aptest.com>
Date: Thu, 05 Aug 2010 12:49:28 -0500
Message-ID: <4C5AF9A8.2090303@aptest.com>
To: Manu Sporny <msporny@digitalbazaar.com>
CC: RDFa WG <public-rdfa-wg@w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:55:07 GMT