Re: Media Fragments / CSS / SVG issue

On Tue, 28 Jun 2011, Robin Berjon wrote:

> Hi Raphaël,
>
> On Jun 28, 2011, at 08:48 , Raphaël Troncy wrote:
>> The background reading is the following 2 threads:
>> * Boris's concerns about backwards compatibility of media fragments with SVG, http://lists.w3.org/Archives/Public/public-media-fragment/2011May/0014.html
>>
>> Our analysis is that SVGview has a XPointer like syntax while the Media 
>> Fragment URI will always have an equal sign which means we don't 
>> generate XML id and we believe that such a fragment cannot be 
>> interpreted in different ways by 2 different processors
>
> I tend to agree with fantasai's reading that while a clash is possible, 
> it's unlikely to occur in practice (and therefore unlikely to break 
> existing content).
>
> I think that one thing which could help the CG in this discussion is an 
> indication of why you chose not to use an XPointer syntax for this? Is 
> it simply because it's not targeting XML content? On the face of it, it 
> would seem to address this issue. And maybe XPointer should be rigged so 
> that it can apply to non-XML content. You mention XPointer in your 
> references, but nowhere else in the text (it's also unclear which of 
> your references are intended to be normative and which simply 
> informative).
>
>>  * Fantasai's concerns about spatial media fragments on an image file 
>> that might have multiple images of different sizes or no clearly 
>> defined size, 
>> http://lists.w3.org/Archives/Public/public-media-fragment/2011May/0019.html
>
> I don't think that this is the email you intended to point to (though it 
> does provide an answer to the previous point), I think you meant: 
> http://lists.w3.org/Archives/Public/public-media-fragment/2011May/0021.html. 
> It would appear that Tab proposed a potential solution to that issue: 
> http://lists.w3.org/Archives/Public/public-media-fragment/2011May/0036.html. 
> On the face of it is seems like a reasonably simple change; are there 
> particular issues with it?

Thinking about it, I am wondering if it is a good thing to let CSS 
interpret what http://www.example.com/multiresimage#xywh=10,20,30,40 means 
by applying its own scheme. It should be based on what the media type says 
about the default resolution when multiple resolutions are present, or 
invalid if the media type is not defining what it means. (and yes, that 
should be in the MF spec, not in CSS).

> In trying to look into this, I've noticed that your error handling uses 
> SHOULDs throughout ? is there a good reason not to use MUSTs instead?
>
>> We are tempted to say that these cases are border cases, undefined for 
>> media fragments (or let to be defined for MF 2.0 or something).
>
> My knee-jerk reaction to leaving things undefined in a specification is 
> to snarl an oath from some Icelandic saga, light a hardcopy of RFC2119 
> on fire and start hitting random people with it :) Before it gets to 
> that, is there not another solution? For instance, if you really don't 
> want to address these cases, can you flag them as errors which must be 
> ignored? There's usually nothing wrong with v2 taking error cases and 
> making them valid so long as the processing required in v1 implies 
> ignoring the content.

I am for doing nothing there until you start hitting random people with a 
burning hardcopy of RFC2119 (on low carbon emission paper, please).

Another issue is that percentages are currently defined as integers, and 
that may be problematic for properly cropping part of a big resolution image, 
should it be relaxed to allow decimals instead of integers?

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Tuesday, 28 June 2011 13:35:13 UTC