- From: Gregg Kellogg <gregg@kellogg-assoc.com>
- Date: Sun, 2 May 2010 17:33:32 -0400
- To: Shane McCarron <shane@aptest.com>
- CC: "public-rdfa-wg@w3.org" <public-rdfa-wg@w3.org>
On May 2, 2010, at 2:11 PM, 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. Note that if I wait until after I've processed it, I'll still be in the same loop, as I cannot complete processing until I've parsed the document, which causes the recursion. The bone-head fix I added was to not parse a vocabulary equivalent to the base URL of the document being parsed. A better fix is to create a cache entry on entry, and check this when looking at a profile to avoid reentry. A separate step would be to pre-populate this cache from well-known vocabularies, which I would leave out during testing. > > 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:34:20 UTC