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

Re: Representing HTTP Requests Responses and Headers in moki

From: Sean Owen <srowen@google.com>
Date: Thu, 24 May 2007 15:59:57 -0400
Message-ID: <e920a71c0705241259v65e7ddben1337fc960e959de1@mail.gmail.com>
To: "Jo Rabin" <jrabin@mtld.mobi>
Cc: public-mobileok-checker@w3.org

On 5/24/07, Jo Rabin <jrabin@mtld.mobi> wrote:
> Q1: Is there any benefit to enclosing each request response pair in an
> element to bind them more closely together?
> Proposed Answer: Probably not as it adds no information.

Agreed, let it be.

> This would have the effect that the XSLT would need different ways of
> accessing header data. Assuming you knew which header you were going for
> this would not be a problem. If you wanted to iterate over all the
> headers it would make the code a bit more complicated. On the up-side it
> is a more simple direct representation, more directly accessible when
> you need to value. On the down-side it means that if you don't know the
> structure of a particular header you need to test for the presence of a
> value attribute before accessing the data.

I agree, it complicates things a bit. I don't see it as a big problem.

> Q2: Which does the team think is the best approach?
> Proposed answer: use the value= representation because then the
> representation of unstructured values of headers, elements and
> parameters is the same, it's the most compact way of doing it and it
> adds to readability.

Sounds good -- would just ask that we "take this resolution" and you
implement it in the code soon to stabilize the representation sooner
rather than later to avoid backtracking and reimplementing tests

> Q3: Parse cookies or anything else?
> Proposed Answer: No. Render their values as value = "..."

Received on Thursday, 24 May 2007 20:00:24 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:18 UTC