Re: [apis] Cross-review of HNReq document and current list of use cases

I forgot to add one point to proposed process:

It is worth, when looking at the gaps, to discuss also which gaps belong to
W3C and which one are better addressed by other groups (I mean, non W3C
groups). Also, if a possible cooperation is envisioned, we could reach out
to such groups.

/g



On Wed, Jul 24, 2013 at 12:05 PM, Giuseppe Pascale <giuseppep@opera.com>wrote:

> @Olivier
> it seems this thread takes care nicely of my ACTION-118, thanks!
>
> @Bin
> see my comments inline
>
>
> On Wed, 10 Jul 2013 07:33:30 +0200, HU, BIN <bh526r@att.com> wrote:
>
>  Speaking of "gap", in my view, the gaps are the "requirements" that
>> haven't been addressed by any technical specification yet.
>>
>
> agree
>
>
>  HNReq is not a technical specification, but more like a set or collection
>> of proposed solutions. Let alone it is also not clear whether those
>> solution-looking use cases in HNReq are "gaps" or not. I personally don't
>> think so. That's why comparing our use cases with HNReq won't help us at
>> all. It will just end up with "my solution can solve your use case".
>>
>
> This statement is not completely true. Let me clarify
>
> 1. what the HNTF did, reflected in the HNReq document (
> http://www.w3.org/TR/hnreq/), is exactly what we are trying to do here,
> not less not more.
>
> 2. the document includes use cases but also requirements, and is
> definitively NOT a collection of proposed solutions. The is an informative
> section about existing technology, but that's really just informative.
>
> 3. the document have a section dedicated to gaps (
> http://www.w3.org/TR/hnreq/#**identified-gaps<http://www.w3.org/TR/hnreq/#identified-gaps>).
> You may disagree with it or say is not complete, but they are explicitly
> listed.
>
> 4. the document was sent to a WG (DAP) and presented to them, and there is
> ongoing discussion on a specification that try to address some (most?) of
> the requirements in the HNReq. document (i.e. http://www.w3.org/TR/**
> discovery-api/ <http://www.w3.org/TR/discovery-api/>). he discussion is
> still ongoing and involvment of interested people is very important to make
> it progress.
>
>
> Last point is very important IMO. Spec work only proceeds if there are
> people interested in making it progress and ready to spend time on it. And
> of course if there are implementers interested in implementing them.
> Unfortunately some of the original contributors to the HNReq document
> didn't join the discussion in DAP. It's important for this group to
> understand that the work doesn't end in the IG, but need to be followed
> when it's moved to a WG. We can't expect to deliver a set of requirements
> to a WG and have them do the work.
>
> That said, my conclusion are probably not too different from yours
>
>
>
>> I suggest that the more effective approach is to focus on "requirement"
>> and related gaps.
>>
>
> agree
>
>
>  - As the first step, it is more important to summarize the concrete
>> requirement from those use cases. I mean the real "what to do", but not
>> "how to do" as described in HNReq.
>>
>
> agree , although I disagree on the characterization of the HNReq document.
> I don't see how the requirements in the HNReq document differs from the
> ones we have written so far (as approach, I mean)
>
>
>  - Once we have requirement, at the second step, we should analyze which
>> requirement have been addressed by which technical specification.
>>
>
> agree, but we should also consider which requirements have been already
> sent to the DAP WG and HTML WG in the past by this group. In this case,
> there is no point in sending them again. People can join the discussion in
> the WG directly.
>
> It will be beneficial though to document this, i.e. which requirements are
> either already addressed or under discussion in which group, so that people
> reading our documents now where the work is going on.
>
>
>
>  - After this analysis, at the third step, we will have a clearer picture
>> of the "gaps", i.e. the requirements that have not been addressed by any
>> specification yet.
>>
>>
> agree, with the usual caveat that some requirements may not be addressed
> by existing specs but under dicussion in existing group. That needs to be
> documented as well.
>
>
> /g
>
> --
> Giuseppe Pascale
> Product Manager TV & Connected Devices
> Opera Software
>