Re: Handling @profile

Hi Shane,

Wouldn't you hope that caching is taken care of by the underlying
protocol requests?

Which is why version numbers in URLs *are* a good idea. :)

(Mixing two threads there.)

Regards,

Mark

On Sun, May 2, 2010 at 10:14 PM, Shane McCarron <shane@aptest.com> wrote:
>
>
> 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:53:59 UTC