- From: Giuseppe Pascale <giuseppep@opera.com>
- Date: Mon, 15 Aug 2011 12:52:23 +0200
- To: "public-web-and-tv@w3.org" <public-web-and-tv@w3.org>
- Message-ID: <op.vz84hlpp6ugkrk@laptop>
Russell, all, I'm going through the approved use cases once again and I have some additional comments. Sorry for not raising them before. My comments are around some text, common to several ISSUEs (ISSUE-26, ISSUE-27,ISSUE-28, ISSUE-29). #1 "Provide extensions to HTML5 <video>, <audio> elements to allow HTML5 to comply with Home Network Media Transport Requirements (mainly transport protocol specific headers)" I think the expression "Home Network Media Transport Requirements" is pretty vague and also the term "provide extensions" seems misleading. Maybe this part could be rephrased with something like "Provide a mean to support additional transport specific headers" #2 "Also, provide backward-compatible extensions to previous HTML versions to support similar functionality (presumably as browser-plugins)." I think this is out of scope and should be removed. This is a product problem not a specification problem. #3 "Allow pages to control future Home Network device classes where the comand sets are not currently known." I think this should be removed as well. I cannot see how we could extract requirement or define a specification to comply with future and unknown requirements. Of course having a flexible architecture that is future proof is a good design goal (and I can add it as such to the requirement document) but I don't think it can be a requirement. cheers, /g -- Giuseppe Pascale TV & Connected Devices Opera Software - Sweden
Received on Monday, 15 August 2011 10:52:54 UTC