13 Jun 2007


See also: IRC log


Shadi, CarlosI, Reinhard
Johannes, CarlosV


Status update on documents for review

<shadi> response to FOAF 0.9: http://lists.w3.org/Archives/Public/public-wai-ert/2007Jun/0030

saz: response was sent to foaf group, on which is worked on by foaf group
... foaf is getting more stable

ci: how are the properties "surname", "family_name" work in international environments (does everybody understand the same under "family_name"

saz: emphasize that we need foaf name especially and not the derivatives

<shadi> mobileOK survey 1: http://lists.w3.org/Archives/Public/public-wai-ert/2007Jun/0031.html

<shadi> mobileOK survey 2: http://lists.w3.org/Archives/Public/public-wai-ert/2007Jun/0033.html

saz: survey 1 is resolutions on the previeous working draft and the resolutions presented by the mobileOK group
... survey 1 is an internal survey to get feedback from our group and collect the information
... I will put together the result of survey 1 and we will discuss them next week
... both surveys are due to next tuesday (19th June)

<shadi> s/results of survey 1/results of survey 1 and survey 2

<shadi> http://www.w3.org/2002/09/wbs/32094/mOK_LCWD_response/

saz: if you agree with resolution, then accept it. If EVERYBODY agrees, there is no need for further discussion.

<shadi> http://www.w3.org/2002/09/wbs/32094/MOKreview/

saz: survey two is for commenting the latest draft.
... we will collect data and send it to mobileOK working group
... put all your comments in the drafted format into the textbox

<shadi> http://lists.w3.org/Archives/Public/w3c-wai-ig/2007AprJun/0038

<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2007Jun/0034.html

<shadi> http://www.w3.org/2002/09/wbs/32094/WCAGreview/

saz: everybody in the group should review the wcag2.0 draft and also fill out the survey
... comments related to ERT (conformace section, testability of the guidelines) need to be highlited
... TODO: mobileOK reading and fill out survey and until 19th we all should look at wcag2.0 and fill out the survey by 26th

<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2007May/0026

<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2007May/0023

saz: earl and powder will be topic again in the weeks after

<shadi> s/earl and poweder/earl guide and powder use-cases

HTTP-in-RDF: "simplified" approach

<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2007May/0024

<shadi> http:MessageHeader

<shadi> |- http:fieldName (rdfs:Literal)

<shadi> |- http:headerName (predefined httph:HeaderName resource)

<shadi> |- http:fieldValue (rdfs:Literal or http:HeaderElement)

<shadi> question: is "accept" == "AcCePt"?

saz: when you convert from fieldName to headerName you loose information. For some tools it makes sense to distinguish between the two versions
... if too

s/if too /this approach could also be repeated for the status-code element also

ci: i have discussed with johannes. With the new approach we have the problem to keep information equally (that the values are the same)
... it is a consistency issue, which is very important
... problem with literals is, how to check the validity. Literals are for typpes of information, that is completly open, not for a closed ste of values

saz: i saw accept headers with values all in small letters but also with capital letters first.
... literal value is the normative one.
... literals are harder to automatically query.
... tools are differnt (some care about capitalisation, some don't)
... you can only provide a literal value if the value consits with the specification

ci: there needs to be a rule which clarifies, the appropriate use for predefined header values
... e.g. when it conforms to the respective RFC

saz: it would be a good direction to use it in the next draft

RESOLUTION: Go ahead with this approach for now

HTTP-in-RDF: date properties for timestamping

<shadi> http://lists.w3.org/Archives/Public/public-wai-ert/2007Jun/0013

saz: johannes proposed dateSubmitted and dateAccepted, but there was disagreement on the list. We should use dc:date

RESOLUTION: We use dc:date for timestamping in request and response

Summary of Action Items

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.128 (CVS log)
$Date: 2007/06/13 19:16:07 $