W3C home > Mailing lists > Public > public-media-annotation@w3.org > March 2012

Re: AW: AW: review the API for Media Resources 1.0 before PR

From: Thierry MICHEL <tmichel@w3.org>
Date: Mon, 26 Mar 2012 18:49:34 +0200
Message-ID: <4F709E1E.2070108@w3.org>
To: "Bailer, Werner" <werner.bailer@joanneum.at>
CC: "public-media-annotation@w3.org" <public-media-annotation@w3.org>

Le 26/03/2012 17:05, Bailer, Werner a écrit :
> Hi Thierry,
> thanks for your updates. Please find my answers to the open issues below.
>> section 4.1.1 Methods:
>> Note1:" it seems methods and attributes are ordered alphabetically - is
>> that done by the stylesheet, and if so, any chance to turn it off?
>> now it is a bit confusing that methods and attributes are in different
>> order in the interface code and in the examples than in this section"
>> I have edited the document manually (the output of the source, not using
>> the script, for this PR version).
>>    If we need to sort differently the methods and attributes are
>> currently ordered alphabetically, this should be done manually.
> OK, I see. It would only be a small improvement, so it's probably not worth all the work of reordering.

If you think it is really necessary we can do that for REC. It is not a 
spec change, but only reordering.

>> Note2: "mode is optional: what happens if omitted, and the
>> implementation supports both modes?"
>> Not sure what statement I should add here.
> I just discussed with Florian. We should state that in the case the mode argument is omitted, and the implementation supports both modes, the asynchronous mode will be used.

Added, see

>>> When preparing the JSON examples, we had a discussion on the list (see
>> thread starting with [1]). Most of the issues discussed have been resolved,
>> but two points are still open IMO (but probably that need not be done
>> before moving the API document to PR):
>>> - There was some unclarity about the use of status codes in the JSON
>> examples, and we also made some smaller changes of the codes in autum, so
>> it would be useful to review them again (and correct, if necessary).
>>> - There are the issues about fragments without identifiers in the source,
>> and resources/fragments with multiple identifiers (see [2]). This is something
>> to go into implementation notes/best practices, either as informative
>> section/annex of the API document or as a separate note.
>> If this is simple enough to be resolved let say during the next telecon,
>> I would be happy to put these in the PR document.
> The point on JSON is probably assigning actions to distribute the work of reviewing.

OK,lets assign action tomorrow during the telecon. This does not impact 
the spec, but only the examples.
> For the second points, we have proposals in the discussion on the mailing list (see [2] below). If we can agree on them, it should be easy to draft some text from it.
OK,lets try to get a resolution tomorrow during the telecon.
If so we can add some text in the PR version.


Received on Monday, 26 March 2012 16:49:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:17:45 UTC