- From: Shane McCarron <shane@aptest.com>
- Date: Thu, 05 Aug 2010 12:49:28 -0500
- 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 UTC