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

Re: Handling @profile

From: Shane McCarron <shane@aptest.com>
Date: Sun, 02 May 2010 16:14:48 -0500
Message-ID: <4BDDEB48.8010300@aptest.com>
To: Gregg Kellogg <gregg@kellogg-assoc.com>
CC: "public-rdfa-wg@w3.org" <public-rdfa-wg@w3.org>

Shane McCarron wrote:
> Oh.... ick.  Thanks for pointing this out.  And yes, implementations 
> should detect profiles that have already been processed and not 
> process them again.  But the spec should say this.
Oh... and to be clear... in my implementation at least I cache profiles 
that I have already processed and only reprocess if the source document 
has been modified since my original processing took place.  I really 
think everyone who can cache should take this approach.
> Gregg Kellogg wrote:
>> Okay, first cut of implementing @profile goes into an infinite loop. 
>> Section 7.5 item 3 indicates that any element containing an @profile 
>> document is processed as indicated in RDFa Profiles (section 9). Test 
>> 0089 contains <head profile="http://www.w3.org/1999/xhtml/vocab">, 
>> which causes the parser to load <http://www.w3.org/1999/xhtml/vocab> 
>> to extract the vocabulary. That vocabulary also contains the same 
>> <head> element, so the parser goes into an infinite loop.
>> Clearly, the parser can check for a recursive call to call an already 
>> opened profile, but the processing instructions should discuss this. 
>> It seems that in the case of < http://www.w3.org/1999/xhtml/vocab>, 
>> it is intended to note that this defines a profile, not requires a 
>> profile. Should processing rules be different the <head>, is the 
>> profile use in this case just wrong? In any case, it looks like an 
>> existing useage pattern that is incompatible with the processing 
>> instructions.
>> Gregg

Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com
Received on Sunday, 2 May 2010 21:15:47 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:47 UTC