Re: earl location pointer methods

Hi,

Jim Ley wrote:
>> Overall:
>>  * We want to have a generic pointer class, and then have each type of 
>> pointer be a subclass of this. Please explain if you think this is not 
>> a good approach.
> 
> I don't particularly see the value, it would just be extra stuff which 
> serves little value - we know it's a pointer if it's being used as a 
> pointer, a specific class adds little, but would of course be easy to 
> do, and might be of more value for non-RDF-y folk :-)

I'm OK without having these pointers be subclasses of a generic pointer class because I agree it adds a lot of overhead with little value. However, I think it may be good to introduce a generic pointer class so that the core pointers can be extended with other types of pointers we are currently not thinking of.


>>  * We also wanted to have an in-between class that holds several 
>> location pointers. Each instance of this class represents exactly one 
>> instance of a location (that may
>> be expressed through several different types of pointers) [1]. Can 
>> this be done?
> 
> So it's 2 different pointers to the same piece of content? as opposed to 
> multiple pointers pointing to different content?

Each result may be applicable to different parts of a test subject. For example, several images do not meet WCAG 1.0 checkpoint 1.1. Each of these images is an instance of the result. Each of these instances can be identified using different types of pointers. So we get a structure like this:

<earl:result>
  <earl:validity rdf:resource="..."/>
  <earl:instance-of-result>
    <!--// each of these pointer point to the same instance //-->
    <earl:xpointer rdf:resource="..."/>
    <earl:htmlpointer rdf:resource="..."/>
    <!--// more pointers, ideally as many as possible //-->
  </earl:instance-of-result>
  <earl:instance-of-result>
    <!--// this is a second instance of the same result //-->
    <earl:xpointer rdf:resource="..."/>
    <earl:htmlpointer rdf:resource="..."/>
    <!--// again, as many pointers as a tool can output //-->
  </earl:instance-of-result>
</earl:result>

Does this make sense?


>> LineCharLength:
>>  * The property name and the class name are very similar and prone to 
>> confusion
>> (they are only different by one letter capitalization). Any 
>> suggestions for other names?
> 
> I think that's fine :)  we should discuss if that's not the case.

I think this may cause problems, I'm happy to propose names.


>>  * Does it make sense to add xsd:integer as the domain for the 
>> line/char/length properties?
> 
> For me it's extra cruft - but why not.

We should define all ranges that we can. This also means strings where appropriate.


>>  * There seems to be recursive referencing of Content and byteContent
>> but I may be confusing this, please confirm that this model is fine.
> 
> a Snippet can either have a byteContent or content or both predicates, I 
> don't see a problem, could it just be a language problem in using
> 
> "Some content that is a snippet of a document, it has been base64 
> encoded." for the rdsfs:content ?
> 
>> XPath:
>>  * Here there seems to be a recursive referencing of Namespace but
>> again I am not sure, please confirm.
> 
> Again I can't see it, could it be my English language description that 
> is confusing?

Sorry, my fault. Its fine, I misread the schema.


Thanks,
  Shadi


-- 
Shadi Abou-Zahra     Web Accessibility Specialist for Europe | 
Chair & Staff Contact for the Evaluation and Repair Tools WG | 
World Wide Web Consortium (W3C)           http://www.w3.org/ | 
Web Accessibility Initiative (WAI),   http://www.w3.org/WAI/ | 
WAI-TIES Project,                http://www.w3.org/WAI/TIES/ | 
Evaluation and Repair Tools WG,    http://www.w3.org/WAI/ER/ | 
2004, Route des Lucioles - 06560,  Sophia-Antipolis - France | 
Voice: +33(0)4 92 38 50 64          Fax: +33(0)4 92 38 78 22 |

Received on Wednesday, 12 July 2006 08:34:11 UTC