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

@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). 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/). 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

Received on Wednesday, 24 July 2013 10:06:16 UTC