W3C home > Mailing lists > Public > public-coremob@w3.org > April 2012

Re: [coremob/level-0] df3f70: Replace incorrect use of "MUST [...] if available"...

From: Cuihtlauac ALVARADO <cuihtlauac.alvarado@orange.com>
Date: Wed, 18 Apr 2012 15:48:02 +0200
Message-ID: <4F8EC612.5080500@orange.com>
CC: public-coremob@w3.org
On 04/18/2012 02:59 PM, James Graham wrote:
> On 04/17/2012 03:51 PM, Cuihtlauac ALVARADO wrote:
>> Hi Tobie,
>>
>> Allow me to express my disagreement with respect to that change, and
>> such kind of change in general.
>>
>> I share your interpretation of RFC 2119. "MUST" is an unconditionally
>> requirement while "SHOULD" is a conditional requirement (i.e. "there may
>> exists valid reasons [...] to ignore [...]"). Replacing "MUST if" by
>> "SHOULD" is formally correct. However, in practice, "MUST if" is far
>> superior to "SHOULD", the former should be preferred. Let me explain why.
>>
>> Basically, the "MUST if" clause comes with text which details the
>> circumstances under which the requirement does apply, while "SHOULD"
>> does not. In our case, we absolutely do not want a device which has a
>> SMS app and the agent is *not* capable to trigger that SMS app using the
>> sms: scheme. That must be avoided. We really want the URI scheme to be
>> dispatched always, unless sending SMS is not possible. This was captured
>> by "MUST ... (if available)", it is no longer by "SHOULD".
>>
>> From test implementation perspective, the "MUST if" is easily turned
>> into a real conditional statement, in contrast, it is impossible to
>> decide, at test execution time, whether failing to comply with a
>> "SHOULD" is actually valid or not.
>
> I don't think there is a testable requirement here anyway. For example I
> might configure my device/ua to do nothing when an sms:// link is
> activated. Or a UA might have built-in support for the sms protocol that
> isn't via the system SMS app. You can't prescribe one correct behaviour.
> I think using MUST requirements where you can't write a testcase is wrong.

To me, what really matters, is to forbid a UA to fail to process 
correctly a scheme when the device is indeed capable and configured to 
handle that scheme. From developer and users perspective that's really 
painful. The thing is there, but you can't use it.

Usually, this kind of things becomes testable by allowing the test 
operator to select the features which are relevant to the system under 
test. For instance, when the test operator knows the UA under test has a 
SMS app, she runs the tests in a mode where the SMS scheme test case is 
mandatory, otherwise that case is not ran. To me, this is testable.

> Possibly what's bogus in the spec is calling out specific protocols. The
> actual requirement seems to be that if a link to a protocol is activated
> that the UA doesn't understand natively, it has the ability to dispatch
> that link to a lower level in the stack e.g. the OS, to handle in some
> way. I still don't know how you would write a testcase for this though.
Received on Wednesday, 18 April 2012 13:49:45 UTC

This archive was generated by hypermail 2.3.1 : Friday, 19 April 2013 17:36:46 UTC