- From: Carlos Iglesias <carlos.iglesias@fundacionctic.org>
- Date: Wed, 19 Sep 2007 15:00:53 +0200
- 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 UTC