Re: Pundit and Open Annotation

Hi Simone,


>>>> It's actually easier than that... the specifications of fragments for
>>>> HTML and XHTML don't allow XPointers.
>
>> I don't think it should be a subclass of FragmentSelector as any
>> system that tried to treat it as a FragmentSelector would end up doing
>> the wrong thing.  Agreed that the structure fits well, so maybe just
>> duplicating it is the right way forwards?
>
> Originally i wanted to ask why the spec says that xpointers are not
> able to describe/catch arbitrary part of an HTML document, since, as
> far as i know, they are actually able to. I agree that xpointers are
> not the official fragments semantic for HTML documents, so we will
> avoid using them directly into browsers.

Assuming you mean section 2.1.4, it talks about fragments for HTML
rather than xpointers. The reason being, of course, that you can't use
an xpointer as a fragment for HTML.  If we do say somewhere that
xpointers can't do that, we should change it :)

> The discussion evolved to "how can we use xpointers and be
> spec-compliant", and on this topic i have another question: can't we
> use the xpointer spec for the fragment part and specify an explicit
> dcterms:conformsTo? Isnt this mechanism supposed to fill exactly this
> use case (read: tell the consumer how to interpret the fragment
> semantic)?

No, because FragmentSelector says that you can join the hasSource and
the selector's rdf:value to form a valid fragment URI, and you can't
do that with an xpointer.

> At least, reading the spec i thought this was conformsTo's goal!

The goal for including conformsTo is to distinguish between:
    http://example.org/index.html#xywh=1,1,2,2   // html spec
and
    http://example.org/image.jpg#xywh=1,1,2,2    // media fragment spec

Jeni Tenison's analysis of fragments for SVG is particularly telling
(and worrying):
    http://www.w3.org/TR/fragid-best-practices/#analysis


>> We could solve this issue with a slight wording change in the
>> specification to clarify what the SVG viewport means in SvgSelector.
>>
>> If the viewport is "0 0 100 100" which should be scaled to the size of
>> the target image (with potentially different ratios for height and
>> width), then the coordinates in the SVG are essentially percentages.
>
> This is a clever solution!! Will have to dig into SVG a bit more, but
> sounds like it covers perfectly my original needs.

All, are there any objections to a clarification along these lines?  I
don't think it changes the meaning of viewport, it just clarifies that
if the dimensions of the SVG are not the same as the dimensions of the
image, that scaling should be performed.

Rob

Received on Sunday, 25 August 2013 17:28:04 UTC