3.6.3 Constraints on XML Representations of Attribute Group Definitions, Schema Representation Constraint: Attribute Group Definition Representation OK, "also apply" MUST be true

Editors instructed to take this list and apply where appropriate.

Some notes on these change proposals may be in order.

1 names are unique

    2.5 "Within a given symbol space, names are unique," are -> MUST
    be (this is covered with a MUST in 3.1.1)

Thanks.


2 all processors have 

    2.6 "All schema processors have appropriate attribute
    declarations" MUST have

Thanks.


3 Propertis in the PSVI

    3.1.1 "Any property not defined as optional is always present"
    MUST be

    3.1.1 "not present are taken to have ·absent· as their value"
    MUST have

These passages are describing the PSVI, not the API or data
structure through which a (conforming) procesor exposes the PSVI.
Although in 1.0 the PSVI is sometimes treated as an abstraction and
sometimes as shorthand for the API or data structure that exposes
that abstraction, we are trying to be more consistent in 1.1.  The
PSVI is information which arises during assessment, and to which we
give names.  The description of the PSVI does have normative force
because processors are required to expose it accurately if they
expose it at all, but these sentences are speaking not of the
normative requirement on processors but on the nature of the
abstraction which they may represent.  The use of MUST seems wrong
here, so I am not making any changes to these sentences.


4 "One of the following"

    3.2.2 "and one of the following is true" one ?== exactly one, at
    least one, at most one?  global comment, many instances of this
    case exist

    3.4.2 CTD w/ complex content {content type} 2.1 "if one of the
    following is true" ... at least?  exactly?

    3.4.2 CTD w/ complex content item 5 [Def:] wildcard element "and
    one of the following" >=1?

    3.4.3 item 2.1 "is one of the following" exactly one?

    3.4.4 "E and T satisfy this constraint if and only if one of the
    following is true"
    3.4.6 Schema Component Constraint: Derivation Valid (Extension)
    item 1.4,

    3.4.6 Schema Component Constraint: Derivation Valid (Extension)
    item 1.4.3.2

    3.4.6 Schema Component Constraint: Derivation Valid (Extension)
    item 1.4.3.2.2.3

    3.4.6 Schema Component Constraint: Derivation Valid
    (Restriction, Complex) item 2,

    3.4.6 Schema Component Constraint: Derivation Valid
    (Restriction, Complex) item 2.2.2,

    3.4.6 Schema Component Constraint: Derivation Valid
    (Restriction, Complex) item 2.3.2,

    3.4.6 Schema Component Constraint: Derivation Valid
    (Restriction, Complex) item 2.4.1

    3.4.6 Schema Component Constraint: Type Derivation OK (Complex)
    item 2

    3.9.4.2 Validation Rule: Element Sequence Accepted (Particle)
    items 2.3, 3

    3.10.4 Wildcard allows Namespace Name "one of the following must
    be true:"

This question has arisen elsewhere; clearly the current boilerplate
wording is problematic.  In many cases, the items in the following
list are mutually exclusive, so that it doesn't really matter
whether "one" means "at least one" or "exactly one" (it can't really
mean "at most one", can it?).  I would be happy to change the words
to try to avoid having the question arise for attentive readers, but
saying "at least one" or "exactly one" suggests that more than one
of the items in the following list might be true.  When that is not
the case, the extra words would be misleading or confusing.

    At least one of the following MUST be true:
    1 x < 1.
    2 x > 10.

In the wording proposal I am preparing, I have left alone those
lists where it is fairly obvious that the items are mutually
exclusive, and changed the wording where "at least one" or "one or
more" is meant.  I hope that suffices.

    3.3.2, {target ns}, Element Decl "and one of the following" at
    least one

This is one of those case where they can't both be true.

    3.7.2 {model group} "among the [children] (there must be one)."
    exactly one

Thanks.


5 MUST vs "is" or "apply" ...
 
    3.2.3 "all of the following also apply" apply -> MUST be true
    (global)

    3.2.6 "all of the following are true" MUST be (global)

    3.4.3 "also apply" MUST be true

    4.2.2 Schema Representation Constraint: Inclusion Constraints
    and Semantics "also apply" MUST be true

    4.2.3 Schema Representation Constraint: Redefinition Constraints
    and Semantics "also apply" MUST be true

    4.2.4.2 Schema Representation Constraint: Import Constraints and
    Semantics "also apply" MUST be true

    3.6.3 Constraints on XML Representations of Attribute Group
    Definitions, Schema Representation Constraint: Attribute Group
    Definition Representation OK, "also apply" MUST be true

XSD 1.0 had a number of lists of the form

    All of the following MUST be true:
    1 The blort MUST be green.
    2 The granfalloon MUST be blue.

It is clear (on reflection) that in such cases the requirement is
that the following propositions be true:

    (P1) The blort is green.
    (P2) The granfalloon is blue.

But the wording of 1.0 (and the wording you suggest) says something
slightly different: it MUST be the case that P1 and P2 MUST be true.
This seems to be a statement in modal logic, making it the
responsibility of the schema procesor to ensure that P1 and P2 are
logically necessary, rather than contingent.  But processors can
seldom control which possible worlds they are run in; perhaps the
conformance requirement is on the possible world, that it be one in
which P1 and P2 are logically necessary rather than contingent.

To avoid this, the spec has been systematically revised to ensure
(modulo failures of consistency) that all lists of conformance
requirements take either the form

    It MUST be the case that all of the following are true:
    1 The blort is green.
    2 The granfalloon is blue.

or the form

    It is the case that all of the following are true:
    1 The blort MUST be green.
    2 The granfalloon MUST be blue.

The change you suggest would put us back in the modal logic
business, and as an editor of the spec I respectfully decline to go
back there.


6 is performed / MUST be performed

    4.2.2 "in which case no corresponding inclusion is performed." 
    -> "in which case the corresponding inclusion MUST NOT be
    performed.

Thank you.


7 The approriate case

    3.3.2, {target ns}, Element Decl "appropriate case" ...do not
    remember the semantic for "case" being defined, but given that
    different languages have this keyword with subtly different
    semantics (does one bail after satisfying one of the conditions
    or continue to evaluate the rest), probably one you need to
    define in 1.5 etc.  I took it to me stop after first true.

In this case, it's clear on examination that only one of the items
can be true at a time.


8 One or two components

    4.2.3 Schema Representation Constraint: Individual Component
    Redefinition "Corresponding to each non-<annotation> member of
    the [children] of a <redefine> there are one or two schema
    components in the <redefine>ing schema:" needs to be re-cast
    into RFC2119 style.  It seems like it wants the appropriate CASE
    amongst the following.

You may be right.  But the XSD 1.0 component story so thoroughly
confuses me that I am loath to try to revise this passage.

3 Properties in the PSVI

Your argument seems "strange" given the context.  Expanding the excerpt ever so slightly, in 3.1.1 we find:

"Any property not defined as optional is always present; optional properties which are not present are taken to have ·absent· as their value. 
 Any property identified as a having a set, subset or list value may have an empty value unless this is explicitly ruled out: this is not the same as ·absent·. 
 Any property value identified as a superset or subset of some set may be equal to that set,"

Thus, in the already existing text, sentence 1 shies away from RFC 2119 vocabulary while both of the next two sentences, I think describing the same PSVI, use RFC 2119-style MAYs.  This seems inconsistent.

4 "One of the following"

> saying "at least one" or "exactly one" suggests that more than one
> of the items in the following list might be true.  When that is not
> the case, the extra words would be misleading or confusing.

Quite true.  I am fine with, and to some level expected, that the wording would be case-specific.  3 eyebrow hairs of concern arise at "fairly obvious that the items are mutually exclusive", since "fairly obvious" is Eye of the Beholder territory.  Most readers of the spec will not have the wg's level of intimate familiarity with the content.  My lowest-cost fix would be to state in 1.5 that in cases where the authors believe the list items to be mutually exclusive, [this language] has been used.  While the authors are most likely right when assessing whether a set of options falls into the ==1, >=1, 0 or 1 sorts of categories, that is still their assessment (dare I say assertion) and hence it may be wrong, however unlikely.

5 MUST vs "is" or "apply" ...

We simply read the suggested words to mean different things.  I mentally append "in order for the constraint to be met" after each of these, which is for most humans functionally equivalent to "in order for the 'thing' to be valid".  So, for me, they are still contingent.  If we want to reduce this down to modal logic, I think by definition you've just lost the majority of humans (regardless of how correct doing so might be).  Taking the first citation as a concrete example:

Schema Representation Constraint: Attribute Declaration Representation OK
In addition to the conditions imposed on <attribute> element information items by the schema for schema documents, all of the following also apply:

Cinching down the language lawyer hat, I have to ask what "apply" even means.  Allowing for a bit more cranial circulation, I think the intent is one (or both, to me they are essentially the same) of the following:

(1) In addition to the conditions imposed on <attribute> element information items by the schema for schema documents, all of the following conditions also are imposed:

(2) In addition to the conditions imposed on <attribute> element information items by the schema for schema documents, all of the following conditions also must be tested:

Either of those would, to me, be an improvement.  I will not lay down in the tracks over it however.

7 The appropriate case

"In this case, it's clear on examination that only one of the items can be true at a time."

Kind of you to prove my point for me.  In certain languages with "case", an otherwise is ALWAYS executed unless the individual when/if tests contain a "break".  It is exactly this potential difference in assumptions I was pointing out.

3 Properties in the PSVI

    Your argument seems "strange" given the context.  Expanding the
    excerpt ever so slightly, in 3.1.1 we find:

        "Any property not defined as optional is always present;
        optional properties which are not present are taken to have
        ·absent· as their value. Any property identified as a having a
        set, subset or list value may have an empty value unless this
        is explicitly ruled out: this is not the same as ·absent·. Any
        property value identified as a superset or subset of some set
        may be equal to that set,"

    Thus, in the already existing text, sentence 1 shies away from RFC
    2119 vocabulary while both of the next two sentences, I think
    describing the same PSVI, use RFC 2119-style MAYs.  This seems
    inconsistent.

Yes, you're right; it is.  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.


4 "One of the following"

    ...  3 eyebrow hairs of concern arise at "fairly obvious that the
    items are mutually exclusive", since "fairly obvious" is Eye of
    the Beholder territory.  ...

Point well taken.

    My lowest-cost fix would be to state in 1.5 that in cases where
    the authors believe the list items to be mutually exclusive, [this
    language] has been used.  While the authors are most likely right
    when assessing whether a set of options falls into the ==1, >=1, 0
    or 1 sorts of categories, that is still their assessment (dare I
    say assertion) and hence it may be wrong, however unlikely.

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


5 MUST vs "is" or "apply" ...

    We simply  read the suggested words  to  mean different things.  I
    mentally append "in order for the constraint to be met" after each
    of these, which is for most  humans functionally equivalent to "in
    order for the 'thing' to  be valid".  So, for  me, they are  still
    contingent.   If we want  to reduce  this down to  modal logic,  I
    think  by  definition you've just  lost   the  majority of  humans
    (regardless of how correct doing so might be).

I should make clear that I don't believe either that the 1.0 spec
intended the rules to be read in the light of modal logic or that 1.1
should do so.  But I found it impossible to read the nested uses of
MUST without stopping to say "well, this clearly doesn't mean what it
says; as a reader I will have to make allowances for that."  We don't
have a lot of other reports, so maybe I'm the only reader who found it
confusing.  Since the WG made the change, however, either I persuaded
them that it was an improvement or they were just humoring me and must
now see the price to be paid for it.

    Taking the first citation as a concrete example:

        Schema Representation Constraint: Attribute Declaration
        Representation OK In addition to the conditions imposed on
        <attribute> element information items by the schema for schema
        documents, all of the following also apply:

    Cinching down the language lawyer hat, I have to ask what "apply"
    even means. Allowing for a bit more cranial circulation, I think
    the intent is one (or both, to me they are essentially the same)
    of the following:

    (1) In addition to the conditions imposed on <attribute> element
    information items by the schema for schema documents, all of the
    following conditions also are imposed:

    (2) In addition to the conditions imposed on <attribute> element
    information items by the schema for schema documents, all of the
    following conditions also must be tested:

    Either of those would, to me, be an improvement.  I will not lay
    down in the tracks over it however.

I like both of these.

    7 The appropriate case

        "In this case, it's clear on examination that only one of the
        items can be true at a time."

    Kind of you to prove my point for me.  In certain languages with
    "case", an otherwise is ALWAYS executed unless the individual
    when/if tests contain a "break".  It is exactly this potential
    difference in assumptions I was pointing out.

I'm not certain that I understand the issue you are raising here.  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.  (Hence the reply, which
suggests that the list in question is not really ambiguous.)

But now you're focusing on the "otherwise", which makes me think I
didn't understand the issue here in the first place.

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

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?

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 worthwhile.

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:

switch
case [condition 1] action 1
case [condition 2] action 2
otherwise          action n
end-switch
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.

A wording proposal intended to resolve this issue is now at 

 http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b5150b.html
 (member-only link)

Suggestion:
1.5's next text dealing with "4 One of the following" issue from earlier comments:
from: "...subsequent cases need not (and indeed must not) be tested."
to:   "...subsequent cases                      must not  be tested."
"need not" reads like a MAY, which contradicts the MUST.

Otherwise, looks good.

The wording proposal mentioned in comment #7 was adopted by the XML Schema
WG on its telcon today.  Accordingly, I'm marking this issue resolved.
John, as the originator of the issue, I hope you will signal your assent 
to this decision by changing the status of the bug to CLOSED, or your dissent 
by reopening it.  If we have not heard from you within the next two weeks or
so, we will assume (encouraged by your comment #8) that silence implies consent.

The amendment suggested in comment #8 has been made.