- From: Mark Birbeck <mark.birbeck@webbackplane.com>
- Date: Sun, 2 May 2010 23:38:50 +0100
- 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, It's not confined to browsers. I'm talking about using a network library in some programming language -- you'll nearly always get caching directives honoured by the library. Consequently, if you have a date or version number in the URL, you can set a very long expiry time on your server, because that document will never change. This is quite a common technique for JavaScript libraries, and would work for profiles and vocabularies, too. Mark On Sun, May 2, 2010 at 11:03 PM, Shane McCarron <shane@aptest.com> wrote: > 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:39:24 UTC