Fwd: RE: MAE comments

Hi, SVG WG-

Cyril asked about outstanding issues on the MAE spec, which he has 
volunteered to take to LC and beyond (I believe).  This is the most 
recent email I could find that had anything substantive; I don't know if 
this has been rolled into the current draft, or even if it was discussed 
and agreed to.  Please let me know if anyone knows of anything else that 
needs to be done.

Thanks-
-Doug

-------- Original Message --------
Subject: RE: MAE comments
Date: Tue, 8 Apr 2008 11:21:39 +0200
From: Andrew Sledd <Andrew.Sledd@ikivo.com>
To: Doug Schepers <schepers@w3.org>, SVG WG <w3c-svg-wg@w3.org>
CC: Erik Dahlström <ed@opera.com>

Thanks Doug,

State Diagram and explanitory prose:
As I recall the state diagram and states themselves are informative and 
not normative. Therefore the prose in that section has not followed the 
requirements of normative prose.

SessionName attribute on MAE interface:
My current position is that there is a need to uniquely associate events 
with a media element, but _no_ need to uniquely identify them to a 
'session'.  The events are raised on a media element and the 'target' 
information is available from the interface. Therefore, the event is 
uniquely identified as originating from the element. So no need for 
SessionName

MediaStreamInfo type/subtype split:
Sounds like we have agreement to combine these in one attribute.

Regards,
Andy

> -----Original Message-----
> From: Doug Schepers [mailto:schepers@w3.org]
> Sent: den 7 april 2008 21:04
> To: SVG WG
> Cc: Andrew Sledd; Erik Dahlström
> Subject: Re: MAE comments
>
> Hi, Andy-
>
> Comments inline...
>
> Andrew Sledd wrote (on 4/7/08 1:08 PM):
> > -----Original Message-----
> >> [mailto:w3c-svg-wg-request@w3.org] On Behalf Of Erik Dahlström
> >
> >> There should be examples showing MAE in use in other
> languages than
> >> SVG, to show that "MAE...can equally well be combined with other,
> >> larger DOM APIs.".
> >
> > OK. Can we defer to later WD or LC WD to incorporate changes?
>
> Yes, we can add non-normative examples or prose to an LC
> draft with no implications for publication schedule.
>
>
>
>
> >> 2. Definitions
> >> --------------
> >> > The Media Access Events namespace is
> >> > http://www.w3.org/ns/media-access-events# .
> >>
> >> Does it have to be so ugly (can we please get rid of the #
> character)?
> >> :
> >
> > This was agreed previously. Proposal for change?
>
> My proposal would be:
>    "http://w3.org/mae"
>
>
>
> > Proposed new wording:
> > Upon successful completion of the session setting on the client,
> > the UA goes into the Session Setup state. An EndSessionSetup
> > event is fired when the initialization of the session is complete.
> > If the session set up between client and server cannot be
> > completed, the UA goes into the Stopped state and fires an Error
> > event.
>
> All wording should be in normative prose.  So, replace all
> uses of the
> copula ("be", "is", "does", "goes") with "must", "should", "may", etc.
>
> Proposed revision:
> Upon successful completion of the session setting on the client,
> the UA must enter the Session Setup state. An EndSessionSetup
> event must be fired when the initialization of the session is
> complete.
> If the session set up between client and server cannot be
> completed, the UA must enter the Stopped state and fire an Error
> event with error code [help me out here].
>
>
> > For Error event, status contains the error code. For other
> events it must be Status_OK.
> > Propose rewording as:
> >    Specifies the status of the event. For the Error event, status
> >    specifices the error code as one of; STATUS_ERROR_ON_SETUP,
> >    STATUS_ERROR_UNSUPPORTED_MEDIA, STATUS_ERROR_CORRUPT_STREAM.
> >    For other event types STATUS_OK must be returned.
>
> Proposed revision:
>     Specifies the status of the event. For the Error event, status
>     must indicate the error code as one of; STATUS_ERROR_ON_SETUP,
>     STATUS_ERROR_UNSUPPORTED_MEDIA, STATUS_ERROR_CORRUPT_STREAM.
>     For other event types STATUS_OK must be returned.
>
>
>
>
>
> >> > getSessionName
> >> >   Returns the name of the media access session .
> >>
> >> The name? Clarify, where does that come from.
> >
> > Propose to remove SessionName.
>
> I'm fine with this if there is another way to uniquely identify the
> session, otherwise let's find a way to identify it.
>
> > New wording:
> > A DataRequest event MUST be fired when the UA sends the
> first request for
> > streamded data to the server.  This event is fired only
> once per session.                    In the case the session
> has multiple streamed data the event is fired after
> > the first request for each data stream has been made to the server.
>
> Proposed revision:
> A DataRequest event must be fired when the UA sends the first
> request for
> streamded data to the server.  This event must be fired only once per
> session.                    In the case the session has multiple
> streamed data, the event must be fired after
> the first request for each data stream which has been made to
> the server.
>
>
>
> >> 5. The MediaStreamInfo interface
> >> --------------------------------
> >> I'd be interested in being able to access the buffering
> levels here.
> >> Otherwise this is a quite useless interface IMHO.
> >>
> >> Why is the media type string split in two in this interface, do we
> >> really need that? Is it really so difficult to split the string in
> >> script instead? I propose to only have one attribute
> "mediaType" or
> >> "type" that can have the values as indicated in IANA Media Type
> >> registry, e.g "video/H264".
> >
> > Don't know why they got separated. Do you feel strongly about this?
>
> MIME Type is fairly commonly understood, best to keep the
> parts together
> for general understandability and compatibility.
>
>
> Regards-
> -Doug Schepers
> W3C Team Contact, SVG, CDF, and WebAPI
>

Received on Friday, 4 September 2009 15:54:53 UTC