W3C home > Mailing lists > Public > public-mobileok-checker@w3.org > June 2007

Re: CachingTest HTTP header re-request

From: Sean Owen <srowen@google.com>
Date: Tue, 26 Jun 2007 10:47:13 -0400
Message-ID: <e920a71c0706260747j3f4e3255ucfe3b0489ad40d9a@mail.gmail.com>
To: "Roland Gülle" <roland@7val.com>
Cc: "Laura Holmes" <holmes@google.com>, public-mobileok-checker@w3.org
I don't think it makes sense to do these re-requests in the
preprocessing phase, since it's only needed in some cases, and doesn't
meaningfully contribute to uses of the intermediate document outside
mobileOK Basic. I think it's pushing this approach a notch too far and
bloats the intermediate doc. In any event that part of the moki doc
hasn't been implemented by anyone yet, so I'd suggest we use Java in
exactly cases like this.

On 6/26/07, Roland Gülle <roland@7val.com> wrote:
>
> Hi Laura,
>
> > Is anyone attached to this implementation for any specific reason?
> > And if so, can you explain to me the logic behind the request being
> > implemented prior to this comparison?
> Im attatched:
> http://docs.google.com/View?docID=w.dgh5r6zs_5cb7gz3&revision=_latest
> but not for specific reason - if you want to attach, go for it!
>
> Actually there is no re-request in the XSLT implemented.
> The XPath:
> <xsl:if test="ancestor::HTTPResponse[1]/following-
> sibling::HTTPResponse[1]
>                       and
>                       not(ancestor::HTTPResponse[1]/following-
> sibling::HTTPResponse[1]/status[@code = '304'])">
> checks the result of the re-request in the moki document, so the
> current implementation needs the 'intelligence' to handle re-request
> in the moki document generator.
>
> The question to all:
> Should be this handled in the moki document generator or should the
> XSLT call java code when this is needed?
>
> Cheers,
>   Roland
>
>
>
Received on Tuesday, 26 June 2007 14:47:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:13:03 GMT