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

Re: Handling @profile

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Sun, 2 May 2010 22:53:23 +0100
Message-ID: <p2s640dd5061005021453y84bb9311g3acb3a05ad05651d@mail.gmail.com>
To: Shane McCarron <shane@aptest.com>
Cc: Gregg Kellogg <gregg@kellogg-assoc.com>, "public-rdfa-wg@w3.org" <public-rdfa-wg@w3.org>
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.)



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

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