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
later.

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

Agreed.
Received on Thursday, 24 May 2007 20:00:24 GMT

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