See also: IRC log
<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2006Oct/0017
shadi: how to reconr sequences of headers that are sent and recoieved from the server
johannesk: summarises his email - http://lists.w3.org/Archives/Public/public-wai-ert/2006Oct/0017
shadi: the sequence of values is very
important
... not sure the importance of sequence in which headers of different types
occur
<shadi> ACTION: saz add an editors note in the WD asking for feedback on potential conflict regarding sequence of *different* header types [recorded in http://www.w3.org/2006/11/22-er-minutes.html#action01]
<CarlosI> probably sequence is not relevant for our use case in both cases but...
<CarlosI> if we wont the HTTP in RDF vocabulary to be stand-alone...
<CarlosI> I think both sequences could be relevant for other use cases
shadi: HTTP protocol makes no assumption on the order of headers
<JohannesK> "Header: Value1\nHeader: Value2" should result in "Header: Value1, Value2"
proposed resolution: in earl, sequence of values should be flattened out into comma seperated string
RESOLUTION: in earl, sequence of values within the same request/response should be flattened out into comma seperated string
shadi: the other scenario - sequence of multiple requests/responses between client and server
<CarlosI> e.g. content negotiation
<CarlosI> several request and response before getting any content
johannesK: record every piece of content seperately in a webcontent class and combine them together
<CarlosI> but if you want to exactly reproduce the same conditions you need to record all the sequence
johannesK: redirects could be captured in
individual webcontent classes
... e.g. redirect = a->b->c, we could capture a,b & c as individual
webcontent classes
<CarlosI> and what are the subjects?
<JohannesK> ACTION: jk to write down some thoughts about his proposal of recording 1. simple request/response pair, 2. content negotiation, 3. redirect [recorded in http://www.w3.org/2006/11/22-er-minutes.html#action02]
shadi: summarizes discussion thus far
davidr: proposes the introduction of a warning property within the result class
<CarlosI> f
<CarlosI> have always thought warnings are QA bad practices in general
<Daniela> sorry, have to leave a bit earlier today ...
johannesK: chaals raised the point, what kind of warning it is?
<CarlosI> not sure if we should support themm in EARL
<CarlosI> they are a can of worms
<CarlosI> almost each warning is unique
<CarlosI> proposal:
<CarlosI> use always one of the current values: pass, fail, etc.
<CarlosI> then...
<CarlosI> we can add a new warning class you can use
<CarlosI> but not associated with any specific value
<CarlosI> yes
<CarlosI> you use alway one of the current values
<CarlosI> and you can additionally provide a warning
<CarlosI> imposible to star working on it until next tuesday
<CarlosI> ok
<CarlosI> ACTION: CarlosI to summarize his proposal about warnings on the mailing list [recorded in http://www.w3.org/2006/11/22-er-minutes.html#action03]
<CarlosI> bye