Re: Media Fragments / CSS / SVG issue

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?

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.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Tuesday, 28 June 2011 09:26:44 UTC