RE: mobileOK intermediate format (moki)

A few obvious points sprang to mind:

 * Will you capture all HTTP request headers (literal/decomposed as for
the response)?
   - I know they're generally DDC so potentially constant, but should
the schema assume that?
   - what happens when DDC changes in the future?
   - I guess you could put them in the "record once" section as "browser
characteristics"
   - of course I am thinking of implementations that will use other UA
simulations

 * I think it would be good to be rigorous about timing points if the
stack is exposing them
   - e.g. not just start-end, but
start-DNS-connect-startRequest-endRequest-startResponse-endResponse
   - or make the schema support 0-N <timing> nodes for extensibility
   - again, not important for mOk per se, but thinking of
implementations that will record performance

 * "decompression is moot"
   - again, I think it may be brave to make the schema assume DDC
requests

 * You need some referentiality between requests - why was a request
made? 
   - was it the root URL?
   - was it as a result of a redirect?
   - was it an object referenced in another request? which?
   - was it linked to from another page? which? (thinking of
implementations that will crawl)
   - i.e. apart from the root, you need one of redirectorID, parentID,
refererID in each request

 * Errors, yes. Like timings, howabout 0-N <error> nodes for
extensibility
   - in general, error classes might include
     - "system" (e.g. checker has broken)
     - "network" (e.g. couldn't get anything)
     - "parser" (e.g. got something, couldn't make sense of it)
     - "test results"
   - NB the boundaries between these classes may not always be clear
cut:
     - Nothing came back: was that my fault or the server's?


Some fleeting thoughts for a Friday am.

James



-----Original Message-----
From: public-mobileok-checker-request@w3.org
[mailto:public-mobileok-checker-request@w3.org] On Behalf Of Jo Rabin
Sent: 19 April 2007 23:35
To: public-mobileok-checker@w3.org
Subject: mobileOK intermediate format (moki)

Hi 

My action was to develop the schema for this, and apologies as it has
taken me longer than expected. Well, given that you expect things to
take longer than expected.

It's very much based on the ideas we developed while batting examples
back and forth between me and CTIC - and it's also taken into account
the requirements we drew up into Dublin.[1] I know there's some stuff
missing (e.g. CSS analysis for MEASURES) and Error examples. Hopefully
not that much.

[1]
http://lists.w3.org/Archives/Public/public-mobileok-checker/2007Apr/att-
0009
/Intermediate_Document_Format.svg

I have really struggled with trying to work the HTTP in RDF stuff in. In
the end, taking Nachos words a couple of weeks ago to heart - viz it
can't be used as RDF if it is in an XML document, I thought the best
thing was to take inspiration from that document, and copy it where
possible. I have taken the opportunity to try to reduce the verbosity
and to allow for single consistent XPATH expressions to extract items of
interest to mobileOK. This is of course a decision that is personal and
can be reversed.

A couple of other points.

a) this is an example doc and not a schema. I'll go about generating a
schema and some documentation once there is some feedback and iteration.

b) I wonder if it would be a good idea to separate out the http part
(and possibly others) into standalone schemas?

c) Error codes. We do need a system of allocating codes for errors,
warns etc infos. Poss we should look at the validation engines and see
what we need to represent before diving too deeply into this.

d) I decided to call it moki. Provisionally.

Jo

Received on Friday, 20 April 2007 08:23:22 UTC