Fwd: Re[6]: Contribution for "Proposed initial draft of "Architecture and Requirements for Web-based Signage Player - Emergency Information Profile"

Ooops.

---------- Forwarded message ----------
From: WOOK HYUN <whyun@etri.re.kr>
Date: 2014-06-02 18:29 GMT+09:00
Subject: Re: Re[6]: Contribution for "Proposed initial draft of
"Architecture and Requirements for Web-based Signage Player - Emergency
Information Profile"
To: Sangwhan Moon <sangwhan@iki.fi>



2014-06-02 9:44 GMT+09:00 Sangwhan Moon <sangwhan@iki.fi>:

> > While we aren't making a normative document here (although I seriously
> wish
> > > we could) making the transport method completely open ended just makes
> life
> > > complicated for implementors.
> >
> >
> >
> > What do you mean "a normative document"?
> > Legally, BGs can make only group notes. Do you mean this?
> > If we find lack of APIs, we can make API drafts unofficially.
> > Then we can propose them to WGs.
>
> I was noting that since we are only working on a group note, being very
> open ended
> and ambiguous is probably acceptable but not ideal. Having everything too
> open ended
> will end up in a group note that neither a implementor or a content
> developer can actually
> refer to, as it's just a collection of ideas and use cases with no
> specifics.
>
> I honestly don't think that there is much of a point in publishing a
> document that can't
> be used as a reference from either side - which is what I was trying to
> point out.
>
>
I completely agree on your opinion.
Technical spec should be clarified for implementation.

By the way, in this BG, we are making a note regarding requirements and
architecture rather than specification.
As a first step, we list up use cases and its requirements, and then, we
need to take a gap analysis for each requirement.
If there are missing APIs or functionalities that can not be supported
current web technologies, we can start drafting technical specification in
CG or WG.

Regards,..




-- 
현욱 드림.