Re: Response to your LC Comment -2395 on Media API spec

James,


We need to wrap up this issue in order to allow the MAWG to move forward 
the Media Ontology spec.


Could you please respond to this email and say:

1- that you cancel your initial formal objection.
2- that you agree to the MAWG proposal, that we don't plan to introduce 
quality parameter as we want to keep a simple list of technical properties.


Best,

Thierry



Le 12/10/2010 16:40, Thierry MICHEL a écrit :
> James,
>
> In your latest email (below) to the MAWG response to your comment, you
> say :
>
> 1. You assume that audio will be accessed in PCM format such as
> audio/L16. We just don't understand how you come to this conclusion.
>
> 2- There seem to be many details for video formats in the Media API spec.
> This is not true. For example the size of a video, 8 bits per channel,
> is not specified. Not sure why you also conclude that there are many
> details for video formats in the Media API
>
>
> Best regards,
>
> Thierry.
>
>
>
>
>
>
>> Dear Thierry,
>
>> Thank you also for your second reply below. There seem to be many
>> details for video formats in the Media API spec, but all the audio
>> format parameters seem to assume that audio will be accessed in PCM
>> format such as audio/L16. If that is the intention, then I would ask
>> only that the PCM sample size (e.g., 16 bits) be included as a
>> parameter along with the sampling rate. Is that acceptable?
>
>> Best regards,
>> James Salsman
>
> On Wed, Sep 29, 2010 at 12:08 AM, Thierry MICHEL <tmichel@w3.org> wrote:
>  > Dear James,
>  >
>  > The Media Annotations Working Group has reviewed the comments you
> sent [1]
>  > on the Last Call Working Draft [2] of the API for Media Resource 1.0
>  > published on 08 June 2010.
>  > Thank you for having taken the time to review the document and to
> send us
>  > comments.
>  >
>  > The Working Group's response to your comment is included below.
>  > Please review it carefully and *let us know by email at
>  > public-media-annotation@w3.org if you agree with it or not*
>  > before [09-Oct-2010].
>  > In case of disagreement, you are requested to provide a specific
> solution
>  > for or a path to a consensus with the Working Group.
>  > If such a consensus cannot be achieved, you will be given the
> opportunity to
>  > raise a formal objection which will
>  > then be reviewed by the Director during the transition of this
> document to
>  > the next stage in the W3C Recommendation Track.
>  >
>  > Thanks,
>  >
>  > For the Media Annotations Working Group,
>  > Thierry Michel,
>  > W3C Team Contact
>  >
>  > 1.
>  >
> http://lists.w3.org/Archives/Public/public-media-annotation/2010Jun/0053.html
>
>  > 2. http://www.w3.org/TR/2010/WD-mediaont-api-1.0-20100608
>  >
>  > -----------------------
>  > Resolution of the MAWG:
>  > -----------------------
>  > About your first issue to include audio/x-speex, please refer to our
>  > previous response to your comment about speex and vp8 for the media
> Ontology
>  > specification.
>  > - Speex is a free audio codec for Free Speech, not a multimedia
> *metadata
>  > formats*.
>  >
>  > We don't plan to introduce quality parameter as we want to keep a simple
>  > list of technical properties.
>  >
>  > To respond to your second issue about section 3.12.5 Samplingrate
> interface
>  >
> http://www.w3.org/TR/2010/WD-mediaont-api-1.0-20100608/#samplingrate-interface
>
>  > The API doc states "no exceptions" at a number of places (for the
> operations
>  > and also for some attributes, which is the case for the
> samplingRate). The
>  > "no exceptions" means that no exceptions are defined when accessing this
>  > attribute. The actual text "no exceptions" in the API doc is generated
>  > automatically based on the Web IDL descriptions. Since no exceptions are
>  > defined on the attributes in our case, this text appears in the
> document.
>  > Note that Web IDL does allow to define exceptions for access of certain
>  > properties (e.g., due to type casting), however we do not include these.
>  >
>  > The API specification does not currently hold a good description of
> why we
>  > do not include exceptions however. Therefore we will add a statement to
>  > clarify it.
>
>
>
> ms

Received on Thursday, 14 October 2010 11:18:04 UTC