RE: UPDATED: Pointers changes and issues

Hi Shadi, 

> COMMENT 1:
> Issue #1: I propose we adopt dc:hasVersion rather than ptr:version

OK for me.
 
> COMMENT 2:
> Issue #6 & #8: I don't think we should merge the two classes, 
> though it may be interesting to have a parent "OffsetPointer" 
> class with a ptr:offset property that is then used 
> differently in the CharOffset or the ByteOffset classes

That's another option.
 
> COMMENT 3:
> Issue #9: I don't think I understand the problem, my 
> understanding so far was that a CSS Selector is something 
> like "h2" or "#id" etc.

Yes, the probem is how are you going to use this kind of pointers. I can imagine two possible scenarios:

A - Use css pointers (css selectors) to point into a css document

In this case you can have a CSS document like:

#1 h1 {
#2   whatever;
#3 } 
#4
#5 h2, h3 {
#6   whatever else;
#7 }
#8
#9 h1 {
#10  something more;
#11}
...

If you use "h1" as a selector pointer within this document you have to lead with the ambiguity that is presented.
Is h1 single pointer always to the first occurrence? Line #1
Is h1 a multiple pointer to all the occurrences? Lines #1 and #9
IS h1 a single pointer to just an occurrence? Then, which one? Line #1 or #9? --> need something more

B - Use css pointer (css selectors) to point into a html document

In this case let's say we have something like:

...
<h1>Hello World</h1>
...
<h2>First attempt</h2>
...
<h2>Second attempt</h2>
...

In this case if you use "h2" as a selector pointer we have more or less the same problems as before.

IMO we should have a well defined model that avoids these ambiguities, for example with a new ptr:occurrence property.
 
> COMMENT 4:
> Issue #11: if we don't drop this pointer (at least for now), 
> then we will need to publish a definition (and algorithm) of 
> what we mean by "HTML Pointer" (possibly in a separate 
> document?). We would also need dc:hasVersion to refer to the 
> version of the pointer definition (we shouldn't worry about HTML5 yet)

I'm also in favour of a placeholder instead of totally drop it out, even we can go ahead with a simple solution (as the element and occurrence one)
 
> COMMENT 5:
> 2.4 CompoundPointer: should ptr_startPointer and 
> ptr:endPointer be ptr:Pointer rather than ptr:SinglePointer?

Don't think so, basically a CompoundPointer is, as currently defined, a set of two SinglePointer. If we change the range to ptr:Pointer we could be entering in a recursivity nightmare.
 
> COMMENT 6:
> 2.4 CompoundPointer: do we need 2.4.3 CharOffsetRangePointer 
> and 2.4.5 ByteOffsetRangePointer? I think using CharOffset 
> and ByteOffset as start and end pointers in a RangePointer 
> should suffice, no?

At first glance, sounds good for me.

> COMMENT 7:
> 2.4 CompoundPointer: how about we have a simple 
> SnippetPointer that can be used with the RangePointer to 
> replace 2.4.2 CharSnippetRangePointer and 2.4.4 
> ByteSnippetRangePointer (as in the comment above)?

If we use base64 for ByteSnippets ptr:snippet will need different ranges in each case. 
 
> COMMENT 8:
> All offsets should use integer values rather than Literal.

Make sense.
 
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, 18 July 2007 13:54:01 UTC