W3C home > Mailing lists > Public > public-wai-ert@w3.org > September 2007

RE: Pointers model

From: Carlos Iglesias <carlos.iglesias@fundacionctic.org>
Date: Wed, 19 Sep 2007 15:00:53 +0200
Message-ID: <09700B613C4DD84FA9F2FEA5218828190265990A@ayalga.fundacionctic.org>
To: "Shadi Abou-Zahra" <shadi@w3.org>, <public-wai-ert@w3.org>



Hi Shadi,

> > Pointer (ptr:pointer)
> > |-PointerGroup
> > | |-RelatedPointers
> > | '-EquivalentPointers
> > |-SinglePointer (ptr:reference)
> > | |-ExpressionPointer (dc:hasVersion, ptr:expression)
> > | | |-XPathPointer (ptr:namespace)
> > | | |-XPointerPointer (ptr:namespace?)
> > | | |-CSSPointer
> > | | '-[HTMLPointer]
> > | |-OffsetPointer (ptr:offset)
> > | | |-CharOffsetPointer
> > | | '-ByteOffsetPointer
> > | |-SnippetPointer (ptr:snippet)
> > | | |-CharSnippetPointer
> > | | '-ByteSnippetPointer
> > | '-LineCharPointer (ptr:line, ptr:char)
> > '-CompoundPointer (ptr:startPointer)
> >    |-StartEndPointer (ptr:endPointer)
> >    |-StartOffsetPointer (ptr:offset)
> >    | |-StartCharOffsetPointer
> >    | '-StartByteOffsetPointer
> >    |-StartSnippetPointer (ptr:snippet)
> >      |-StartCharSnippetPointer
> >      '-StartByteSnippetPointer
> >
> > [...]
> >
> > - It uses StartCharOffsetPointer and StartByteOffsetPointer instead a
> generic StartOffsetPointer that makes use of the Single OffsetPointers to
> avoid the duplication of ptr:reference (startPointer and OffsetPointer)
> that may give way to inconsistence if they are different (a
> CompoundPointer should exist only within a unique resource).
> >
> > - The same as above with StartSnippetPointers
> 
> This solution is far from optimal in my opinion. What if I want to
> introduce a new XYZOffsetPointer? Since it is easy to do a query like
> ("offsetNode" rdf:type ?) and find out what kind of a pointer type it
> is, I don't think it is a good idea to be that restrictive.


I'm afraid that I'm not following you here. Could you elaborate please? 
Also note that we're already been that restrictive with OffsetPointers (CharOffsetPointer and ByteOffsetPointer)


> > That leads us yet to one issue: we have yet a duplication of
> ptr:reference that could lead to inconsistence in StartEndPointers as
> startPointer and endPointer are both SinglePointers. We have a similar
> problem with EquivalentPointers
> >
> > Any thoughts?
> 
> Maybe this makes sense. For example, consider this:
> 
> StartPointer:
>   - reference: http://www.example.org/page.html#section1
>   - (XPath) expression: relative to the ID "section 1"
> EndPointer:
>   - reference: http://www.example.org/page.html#section3
>   - (XPath) expression: relative to the ID "section 2"
>
> Similar situations could be constructed for EquivalentPointers,
> especially if there are GET parameters in the reference URI. I think
> this model is fine with regards to the reference.


I think that if we allow these situations we get more dangers than benefits. You can always express your previous example or similar ones like:

StartPointer:
   - reference: http://www.example.org/page.html
   - (XPath) expression
EndPointer:
   - reference: http://www.example.org/page.html
   - (XPath) expression

But, what if you get something like:

StartPointer:
  - reference: http://www.example.org/page1.html
  - (XPath) expression
EndPointer:
  - reference: http://www.example.org/page2.html
  - (XPath) expression

Does it make any sense as a Range?
IMO a model that cares about data consistency and integrity is also important.

 
> > [1] - [http://lists.w3.org/Archives/Public/public-wai-
> ert/2007Jul/0042.html]
> > [2] - [http://lists.w3.org/Archives/Public/public-wai-
> ert/2007Jul/0049.html]


Regards,
 CI.

--------------------------------------

Carlos Iglesias

CTIC Foundation
Science and Technology Park of Gijón
33203 - Gijón, Asturias, Spain

phone: +34 984291212
fax: +34 984390612
email: carlos.iglesias@fundacionctic.org
URL: http://www.fundacionctic.org
Received on Wednesday, 19 September 2007 13:00:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:28 GMT