W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > April to June 2008

[Bug 5151] pseudo-normative qualifications used in apparently normative contexts

From: <bugzilla@farnsworth.w3.org>
Date: Sat, 10 May 2008 15:35:40 +0000
To: www-xml-schema-comments@w3.org
Message-Id: <E1Jur6q-0004uM-4X@farnsworth.w3.org>


------- Comment #6 from johnarwe@us.ibm.com  2008-05-10 15:35 -------
3 Properties in the PSVI

> I think the error is the use of conformance
> language in the sentences containing "may".  But at the moment I do
> not have a good reformulation for them.

may -> might seems to read reasonably well, and "might" is not one of the nudge
nudge wink wink keywords from 2119

4 "One of the following"

> Sometimes I worry that 1.5 is getting kind of crowded, but I think
> this works for me.

It's a big spec.  It uses a number of idioms to avoid enlarging exponentially. 
No matter how large 1.5 grows, if it's a net reduction of the overall spec it's

7 The appropriate case

> I thought at first that it was "What happens if in a series of "if
> <condition> then <result>" items, more than one condition is
> satisfied?", which makes a difference in just those lists where the
> conditions are not mutually exclusive.  

This is one case I was poking at, that you have I think answered
satisfactorily, so I shifted to a different subset (another case) of those I
was poking at in toto.

The general construction of the text is, in a rough approximation of the C
programming language:

case [condition 1] action 1
case [condition 2] action 2
otherwise          action n
action n+1

What I was pointing out is: based on what programming languages the reader
knows, the reader might expect different results in a situation where
[condition 1] is met; following the execution of (action 1), I believe you are
implicitly asserting that the only possible flow of execution is to (action
n+1).  This is consistent with the behavior of many (but not all) programming
languages.  In C, for example, execution flows from action 1 to action n+1 ONLY
if action 1 contains a "break" instruction.  In the absence of a break w/in
(usually at the end of) action 1, [condition 2] would be evaluated, and if true
(action 2) would also execute, and so on through each case+otherwise.  In such
a construct with zero "break"s, the otherwise ALWAYS executes.

See http://www.cprogramming.com/reference/switch.html for a syntactically
correct example.

So your original response, that conditions 1 through n-1 are mutually
exclusive, is a sufficient answer only in the absence of an otherwise.  In
cases where an otherwise exists, the ambiguity remains.

> Would rephrasing the boilerplate help?  And if so, then rephrasing it how?

Perversely, what seems like a very tidy solution presented itself in the course
of explaining the switch behavior above.  If, as seems to be the case, whenever
the current text says "the appropriate case amongst the following" you intend
only a single clause to fire/execute, then:
from: the        appropriate case amongst the following
to  : the single appropriate case amongst the following
If there are situations where >1 condition might be true, use 'first' instead
of 'single' if you have that intent.  "First" might even be your actual intent
all the time.

> Or if really the only thing for it is to say explicitly in section 1.5
> what this idiom means, then (I'm sorry to be so dense) what exactly do
> you believe we should say about it, to make it clearer to readers?

Something like:
In many place, such as the definition of various constraints, a list of
constraints is preceded by the text "the appropriate case among the following".
 The latter should be read to mean that each immediately subordinate condition
in turn is tested; if any condition is satisfied the associated <b>then</b> is
processed, and subsequent conditions are not tested.

FWIW, I don't like this last alternative much myself - too abstract.  It might
be possible to clarify it by example, but I'm not sure that's worth the work.
Received on Saturday, 10 May 2008 15:36:13 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:50:08 UTC