Re: Handling @profile

No.  Because I don't think I am implementing in a browser. And I maintain that most interesting implementations will be outside of a support context like that.  

"Mark Birbeck" <mark.birbeck@webbackplane.com> wrote:

>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
>>
>>
>>
>>
>

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Received on Sunday, 2 May 2010 22:03:55 UTC