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 23:38:50 +0100
Message-ID: <y2n640dd5061005021538o642351fbj26ef276919d013c1@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,

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

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