[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [tag] ambiguity in current TAG draft
Another reason for *some* cases using negative prescription level values: A conformance profile restricting a previous conformance profile will likely wish to restrict some of the the 'Permitted' values of presciption levels to something equivalent to MUST NOT - avoiding the need to change the predicate from A=B to A!=B. Having the ability to use 'Not Permitted' would be helpful. 2008/11/27 Stephen Green <stephen.green@documentengineeringservices.com>: > I agree the last example does not *need* a negative prescription level > >> >> >> normative source: x MUST NOT do y >> >> target: x >> >> predicate: [target x] does y >> >> prescription level: not permitted >> > > The above is correct use of the *negative* prescription level > > >> >> >> Which so far we do not endorse. >> >> >> >> while: >> >> normative source: x MUST NOT do y >> >> target: x >> >> predicate: [target x] does not do y >> >> prescription level: not permitted >> >> > > > This second example should instead be: > > normative source: x MUST NOT do y > > target: x > > predicate: [target x] does not do y > > prescription level: permitted > > > > I would not want to push the argument in favour of 'allowing' or 'accommodating' > the negative prescription levels too much. However, the main argument in their > favor seems to me to be the fact that they do already exist as a standard in the > relevant RFC and this is probably for a good reason. After all, they > need not exist > in specifications either since the requirement could have been written > > > normative source: x MUST not do y > > But is there *ever* a subtle difference between > > normative source: x MUST not do y > and > normative source: x MUST NOT do y > > ? > > I suspect there is but that to regard the MUST NOT as redundant in favor of > 'MUST not' is probably not going to do much harm. It might be worth endorsing > a three-positive-value-only prescription level codelist just for the > benefit of being > able then to say that a predicate MUST always evaluate to 'true' when fuliflling > the normative requirement(s). So I'm happy to drop the argument since there is > some benefit in doing so and the benefit of keeping the 'MUST NOT' equivalent > Prescription Level and 'SHOULD NOT' equivalent is not easy to see or > demonstrate. However I have a feeling it does exist in more complex cases - but > that can be left to a more advanced treatment of TAs which might endorse the > corresponding extension of the prescription level list. > > Best regards > > Steve > > -- > Stephen D. Green > > Document Engineering Services Ltd > > > > http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice > > > > 2008/11/27 Durand, Jacques R. <JDurand@us.fujitsu.com>: >> >> I think we have an ambiguity in current TAG draft, revealed by the SCA use >> case: >> >> - When a normative statement is of the kind "x MUST NOT do y" , the natural >> way (in fact, the recommended way) to write the predicate is: >> "[target x] does not do y" >> >> Then, what should be the prescription level? >> (a) MANDATORY? >> (b) NOT PERMITTED? >> >> >> (a) is aligned with both our definiions of predicate and of prescription >> level in 2.1: >> >> Predicate >> >> A predicate asserts, in the form of an expression, the feature (a behavior >> or a property) described in the referred specification statement(s). If the >> predicate is an expression which evaluates to "true" over the test assertion >> target, this means that the target exhibits this feature. "False" means the >> target does not exhibit this feature. >> >> Prescription Level >> >> A keyword that qualifies how imperative it is that the requirement referred >> in Normative Source, be met. See possible keyword values in the Glossary. >> >> >> >> (b) is aligned with the Glossary definition of prescription level : >> >> >> >> The test assertion defines a normative statement which may be mandatory >> (MUST/REQUIRED), not permitted (MUST NOT), permitted (MAY/OPTIONAL) >> preferred (SHOULD/RECOMMENDED) or not recommended (SHOULD NOT). This >> property can be termed its prescription level. >> >> >> >> The problem I see with allowing/recommending "negative" prescription levels, >> is that this entices the TA writer to write "negative" predicates (=true >> means violation), e.g.: >> >> >> >> normative source: x MUST NOT do y >> >> target: x >> >> predicate: [target x] does y >> >> prescription level: not permitted >> >> >> >> Which so far we do not endorse. >> >> >> >> while: >> >> normative source: x MUST NOT do y >> >> target: x >> >> predicate: [target x] does not do y >> >> prescription level: not permitted >> >> >> >> Would be confusing and sound like a double negation ("not permitted" for >> target to NOT do y) >> >> >> >> Do we really need negative prescription levels, and if yes how do they work? >> >> >> >> Jacques >> >> >> >> >> >> > -- Stephen D. Green Document Engineering Services Ltd http://www.biblegateway.com/passage/?search=matthew+22:37 .. and voice
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]