Re: ISSUE-2: What is the mime type of a media fragment? What is its relation with its parent resource?

Raphaël,

> I don't see why it is 'against the rules' to let the media fragment
> semantics unspecified for some media type? I use exactly the same
> argument that you have, but my interpretation is the opposite. It seems
> to me that RFC3986 saves us because of the second statement: "If
> no such representation exists, then the semantics of the fragment are
> considered unknown and are effectively unconstrained." and I think this
> is the framework we would like to be. Why that is against the rules?

I (hope) I never said that this is against the rules. Ok, let's step back
and see where my thinking comes from (I might be wrong, though, in which
case I'd be happy to learn - from Yves or from whoever ;)

1. We want to specify W3C REC for a *syntax* for URI fragments in order to
address spatio-temporal fragments of media items.

2. In order to become a W3C REC we need to go REC track, including Test
Cases (for CR exit).

3. In order to write Test Cases for our spec, the semantics of the URI
(fragment) addressing a certain media fragment must be defined somewhere
(most likely in natural language, though I would love to do this in, say,
Prolog ;)

I've recently gone through this in RDFa. No fun without the paper trail,
believe me. TAG would most likely tear us apart before we knock on their
door.
 
Cheers,
      Michael

-- 
Dr. Michael Hausenblas
DERI - Digital Enterprise Research Institute
National University of Ireland, Lower Dangan,
Galway, Ireland, Europe
Tel. +353 91 495730
http://sw-app.org/about.html


> From: Raphaël Troncy <Raphael.Troncy@cwi.nl>
> Organization: CWI
> Date: Tue, 27 Jan 2009 15:35:16 +0100
> To: Michael Hausenblas <michael.hausenblas@deri.org>
> Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, Media Fragment
> <public-media-fragment@w3.org>
> Subject: Re: ISSUE-2: What is the mime type of a media fragment? What is its
> relation with its parent resource?
> 
> Dear Michael,
> 
>>> First, that is not possible, as we have already discussed it, since for
>>> updating IANA registries, you need to 'own' the format, which obviously
>>> we don't. It seems to me insane to try to register the fragment
>>> semantics for the 100+ multimedia formats, without counting all new ones
>>> appearing every year ...
>> 
>> Not a matter of being sane or not. A matter of being in-line with the
>> overall paper-trail or not. If you don't like the rules, try to change them.
>> I didn't say that this the only option we have in principle, but the only
>> clean solution I see in the current context.
> 
> I don't see why it is 'against the rules' to let the media fragment
> semantics unspecified for some media type? I use exactly the same
> argument that you have, but my interpretation is the opposite. It seems
> to me that RFC3986 saves us because of the second statement: "If
> no such representation exists, then the semantics of the fragment are
> considered unknown and are effectively unconstrained." and I think this
> is the framework we would like to be. Why that is against the rules?
> 
>>> Third, that was not really the question asked in the ISSUE, although, I
>>> agree it is not completely clear.
>> 
>> Then, please, phrase the questions so that they are unambiguous. Still I see
>> an issue here and you may want to choose to create a new one for 'my' issue.
> 
> Oh please, do so. Do you have permission using the tracker web
> interface? If you don't, then please, let me know. Note that the tracker
> does not automatically send (yet) an email to the list, we are working
> on that with Yves, so you would need to send an email manually once the
> issue is created (sorry for the inconvenience).
> Cheers.
> 
>    Raphaël
> 
> -- 
> Raphaël Troncy
> CWI (Centre for Mathematics and Computer Science),
> Science Park 123, 1098 XG Amsterdam, The Netherlands
> e-mail: raphael.troncy@cwi.nl & raphael.troncy@gmail.com
> Tel: +31 (0)20 - 592 4093
> Fax: +31 (0)20 - 592 4312
> Web: http://www.cwi.nl/~troncy/

Received on Tuesday, 27 January 2009 14:48:12 UTC