- From: Sean Owen <srowen@google.com>
- Date: Tue, 26 Jun 2007 10:47:13 -0400
- 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 UTC