RE: feedback on data format for WCAG-EM reports

Hi Shadi,

Thanks for the fast response! Great stuff! I'll address the key issues below:

> # webPage
>   - EARL does not provide such a class -- might be good to add here;
>   - also needs to consider the notion of "web page states";
Wilco: I think this should maybe be a subclass of http:Response with an optional 'state' property added to it. I think that addresses both issues.


> # reliedUponTechnology
>   - maybe this should be a class too? with dct:title and a URI to any publicly available specification for the technology;
Wilco: Excellent idea. I'll work that into the file


> # dct:conformsTo
>   - actually WCAG-EM results do not include conformance claims;
Wilco: You are absolutely correct. I'll change this.


> # additionalRequirement
>   - could also be a list; maybe rename to additionalEvalRequirement?
Wilco: All of these are properties of the evaluation class, so I didn't add 'eval' to any of the names. Though admittedly that makes them a bit vague here and there. I guess it's a question of consistency. I'm not bothered either way. I will leave this up to your best judgement.

> # dct:date
>   - what does this date stand for? is it different from dct:date in earl:TestResult class (provided for each assertion individually)?
Wilco: This is date is the property of the evaluation. In WCAG-EM it's described as "Date for the evaluation (completion date or duration period)". I think dct:date fits this sufficiently. The date on each individual earl result in my thinking was going to be a time stamp of when it was entered. It helps to account for issues in a report that might have already been fixed before the report was completed. This occasionally happens to me and colleges.


> # Specifics
>   - what is that?
Wilco: Evaluation specifics is one of the things WCAG-EM has as an optional part of reporting. It seems to be a bit of a catch all option for evaluators to record any miscellaneous details. I could rename it to evalSpecifics, like you suggested for additionalRequirement. I am not sure if that makes all that much of a difference. 


> # dct:abstract
>   - I like reusing existing terms but I need to re-read the definition;
Wilco: This is a summary of the evaluation for in the report.


> # commonPages
>   - think this should be a list of webPage;
> # essentialFunctionality
>   - also could be a list;
> # otherRelevantPages
>   - think this should be a list of webPage;
Wilco: The list question is an interesting one. I do not think these should be web pages. This will be part of the exploration, and I think it would be sufficient for users to provide titles or names of sections or any other kind of textual indication they can use during this step. We could allow this in webPage, but I think that wouldn't be sufficient once an auditor is defining their sample.
As for the lists, I think this makes sense from a data perspective. I did not do this because I don't think I want to force auditors into using some sort of widget to define lists. I think a single textarea for any of these things would be better as it would give them more flexibility.
I suggest leaving this issue open until we figure out what we want these fields to look like in the tool and then match the output from that to the data format. 


> # structuredSample and randomSample
>   - maybe create an abstract "webPageSample" class for the two?
Wilco: Makes sense to me. I haven't really looked at subclasses or anything like that. I'll add this to the file.


> # Misc other comments
>   - maybe also need an overall "wcagem:Report" class?
Wilco: By report, do you mean that this would be a pointer to where the report could be found or what it's HTML would be? I can see some advantages, but I could also see some problems arising from that as it is basically a duplicate of the data in a different format. It's worth exploring though.

>   - maybe package conformanceTarget, commissioner, and additionalRequirement into an abstract wcagem:EvaluationScope class?
Wilco: Good point. I just realized there are actually two different ways the word 'scope' is used in WCAG-EM. The evaluation scope (step 1) and the website scope (step 1a). I'll better distinguish between the two. Should I then also add the website to the evaluationScope? That way you would go: evaluation > evaluationScope > website > websiteScope


Regards,

Wilco

Received on Thursday, 26 June 2014 08:10:11 UTC