<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "https://www.w3.org/Bugs/Public/page.cgi?id=bugzilla.dtd">

<bugzilla version="5.0.4"
          urlbase="https://www.w3.org/Bugs/Public/"
          
          maintainer="sysbot+bugzilla@w3.org"
>

    <bug>
          <bug_id>6014</bug_id>
          
          <creation_ts>2008-09-02 14:29:11 +0000</creation_ts>
          <short_desc>[schema11] normative text problems</short_desc>
          <delta_ts>2009-04-20 21:09:50 +0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>XML Schema</product>
          <component>Structures: XSD Part 1</component>
          <version>1.1 only</version>
          <rep_platform>PC</rep_platform>
          <op_sys>Windows XP</op_sys>
          <bug_status>CLOSED</bug_status>
          <resolution>FIXED</resolution>
          
          
          <bug_file_loc></bug_file_loc>
          <status_whiteboard></status_whiteboard>
          <keywords>resolved</keywords>
          <priority>P2</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>CR</target_milestone>
          
          
          <everconfirmed>1</everconfirmed>
          <reporter name="John Arwe">johnarwe</reporter>
          <assigned_to name="C. M. Sperberg-McQueen">cmsmcq</assigned_to>
          <cc>cmsmcq</cc>
    
    <cc>David_E3</cc>
          
          <qa_contact name="XML Schema comments list">www-xml-schema-comments</qa_contact>

      

      

      

          <comment_sort_order>oldest_to_newest</comment_sort_order>  
          <long_desc isprivate="0" >
    <commentid>21730</commentid>
    <comment_count>0</comment_count>
    <who name="John Arwe">johnarwe</who>
    <bug_when>2008-09-02 14:29:11 +0000</bug_when>
    <thetext>1.5 Documentation Conventions and Terminology - deprecated
from: although some processors may choose to issue
to  : although some processors MAY choose to issue

3.12.3 Constraints on XML Representations of Type Alternatives
&quot;No &lt;alternative&gt;  element may have more than one of these, and each must have at least one of these. &quot;
No...MAY seems destined to be mis-read.  Feels like it wants to be a MUST (have at most one), prefer this, or MUST NOT (have &gt;1)

4.2.1 Conditional inclusion
&quot;Where they appear, the attributes vc:minVersion and vc:maxVersion are treated ... then the element on which the attribute appears is to be ignored&quot;
Does anyone really think describing things in terms of what it&apos;s not (i.e. negatively) is better than positively?
Realizing where you are in the process, since I think this IS correct as stated (though it took several passes for me to catch the not&apos;s and un-&apos;s I missed the first time), I&apos;d settle for a non-normative summary stated in the &quot;include if&quot; positive sense.

4.2.2 Assembling a schema &lt;include&gt; clause 1
&quot;It is not an error for the ·actual value· of the schemaLocation [attribute] to fail to resolve at all, in which case the corresponding inclusion must not be performed.&quot;
why maintain this unpleasant dark corner, if redefine and override etc all want to mandate resolution?
is this just FUD masquerading as backward compatibility, or are there well-known concrete scenarios that depend on this behavior?

4.2.4 Overriding component definitions
Schema Representation Constraint: Override Constraints and Semantics clause 4.1.1, 4.2.1
&quot;Let D2&apos; be a &lt;schema&gt; information item obtained by . Then ...&quot; ??? something missing &apos;by .&apos;

4.2.4 Overriding component definitions
Schema Representation Constraint: Override Constraints and Semantics clause 4.1.2
&quot;Note: One effect of the rule just given...&quot; I cannot tell, due to previous comment&apos;s missing text 

4.2.4 Overriding component definitions
Schema Representation Constraint: Override Constraints and Semantics clause 4.1.2
&quot;Note: Another effect is...&quot;  You handle A &lt;override&gt; B &lt;override&gt; C
It&apos;s not clear if there is deterministic behavior in the Y case: both B and C &lt;override&gt; A with conflicting specifications.
&lt;include&gt; clause 3.1.2 in particular, if 2.1 fires, seems to tell me I cannot &quot;build up&quot; a ns with components from several non-overlapping &lt;schema&gt; items...since I think this is possible today, not convinced I&apos;m reading it right.
It also sounds like it prescribes an order of processing, but I had the impression that different orders were permissible (lazy retrieval strategies) which seems to conflict with that impression.

5.2 Assessing Schema-Validity - strict 
...&quot;if they do not identify any declaration or definition, then no schema-validity assessment is performed. &quot;
This appears to say that the result is implementation-dependent.  I rather expected some prescribed output, either an error or values for [validation attempted] etc.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>21821</commentid>
    <comment_count>1</comment_count>
    <who name="C. M. Sperberg-McQueen">cmsmcq</who>
    <bug_when>2008-09-08 15:16:23 +0000</bug_when>
    <thetext>I&apos;m marking this as editorial, since almost all of the points raised
involve rephrasing the wording to make it clearer and eliminate apparent
contradictions.

Two points probably require special treatment:  the comment on 4.2.2 and
schema composition probably should be discussed by the WG (although 
speaking for myself I see little probability that the WG will be able to
do more than shrug and say &quot;we haven&apos;t been able to clear up this dark corner
in six years of trying; we don&apos;t know any more now than we did then&quot; and
reaffirm its decision to leave the Augean stables of schema composition
uncleansed).

The comment on 5.2 intersects with another issue I have been intending to
raise personally, and will be pointed to from that issue.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>21870</commentid>
    <comment_count>2</comment_count>
    <who name="John Arwe">johnarwe</who>
    <bug_when>2008-09-11 18:50:28 +0000</bug_when>
    <thetext>The SML working group did not choose to endorse (or not to endorse) this bug on its call of 2008-09-11
</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>24723</commentid>
    <comment_count>3</comment_count>
    <who name="C. M. Sperberg-McQueen">cmsmcq</who>
    <bug_when>2009-04-14 19:06:04 +0000</bug_when>
    <thetext>A response to these comments has been sent via email and is archived at

  http://lists.w3.org/Archives/Public/www-xml-schema-comments/2009AprJun/0064.html

The changes proposed as resolutions of some of the points raised in the bug
report can be seen in context at

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

and await WG action.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>24797</commentid>
    <comment_count>4</comment_count>
    <who name="David Ezell">David_E3</who>
    <bug_when>2009-04-17 16:24:59 +0000</bug_when>
    <thetext>6014 (John Arwe): Proposal for issue 6014 [schema11] normative
text problems
http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b6014.html

Summary: straightforward clarifications and corrections.

MSM&apos;s recommendation: adopt quickly, without discussion.

Ammendment:

&lt;cmsmcq_&gt; in 3.12.3, make second sentence of the relevant paragraph read:
&lt;cmsmcq_&gt; Each &lt;alternative&gt; element MUST have one and only one of these.
</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>24834</commentid>
    <comment_count>5</comment_count>
    <who name="C. M. Sperberg-McQueen">cmsmcq</who>
    <bug_when>2009-04-18 14:27:51 +0000</bug_when>
    <thetext>The changes described in comment 4 have now been integrated
into the status-quo documents.  

John, if you would indicated in the usual way whether you are
satisfied or dissatisfied with the disposition of the comments,
it would be helpful.  If we don&apos;t hear from you in ten days we
will assume you to be content.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>24854</commentid>
    <comment_count>6</comment_count>
    <who name="John Arwe">johnarwe</who>
    <bug_when>2009-04-20 16:31:26 +0000</bug_when>
    <thetext>(In reply to comment #5)
&gt; The changes described in comment 4 have now been integrated
&gt; into the status-quo documents.  

It appears the amendment from comment #4 was not incorporated as stated (although the spirit appears the same, comment #4&apos;s amendment is clearer to me).

The rest seems fine.

&gt; It&apos;s not clear if there is deterministic behavior in the Y case: both B and C
&gt; &lt;override&gt; A with conflicting specifications.

I&apos;m not clear how the logical grouping of A &lt;override&gt; B &lt;override&gt; C is forced to be A + (B + C) but I have to believe it for now.</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>24858</commentid>
    <comment_count>7</comment_count>
    <who name="John Arwe">johnarwe</who>
    <bug_when>2009-04-20 17:24:10 +0000</bug_when>
    <thetext>&gt; I&apos;m not clear how the logical grouping of A &lt;override&gt; B &lt;override&gt; C is forced
&gt; to be A + (B + C) but I have to believe it for now.

I see now it is artfully described in Appendix G.

I will leave the state of this bug alone to signal the editors that comment #6 reflects a -possible- to-do for the editors to integrate the text described in the amendment contained in comment #4.

If the editors are either happy with the text as it currently is, or if the editors choose to integrate the text described in the amendment contained in comment #4, then this bug may be immediately closed as satisfying me without further review on my part (and since this bug was not endorsed by the SML wg, &quot;that is all&quot;).
</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>24861</commentid>
    <comment_count>8</comment_count>
    <who name="C. M. Sperberg-McQueen">cmsmcq</who>
    <bug_when>2009-04-20 17:47:34 +0000</bug_when>
    <thetext>John Arwe says in comment 6:

    It appears the amendment from comment #4 was not incorporated
    as stated (although the spirit appears the same, comment #4&apos;s
    amendment is clearer to me).

I may be missing something, or looking in the wrong place.  But
comment 4 says, I think:

    In 3.12.3, make second sentence of the relevant paragraph
    read: Each &lt;alternative&gt; element MUST have one and only one
    of these.

In the status-quo document, the paragraph which is the entire
text of Schema Representation Constraint: Type Alternative
Representation OK reads:

    In addition to the conditions imposed on &lt;alternative&gt;
    element information items by the schema for schema documents,
    every &lt;alternative&gt; element must have a type attribute, or a
    complexType child element, or a simpleType child
    element. Each &lt;alternative&gt; element MUST have one and only
    one of these.

That looks to me as if the amendment in comment 4 was executed
correctly: the second sentence of the paragraph reads &quot;Each
... these.&quot;

(I find myself thinking of an old Doonesbury strip in which
Zonker asks Honey &quot;OK, which one of us is stoned this time?&quot;)

He also asks about associativity of override.

    I&apos;m not clear how the logical grouping of A &lt;override&gt; B
    &lt;override&gt; C is forced to be A + (B + C) but I have to
    believe it for now.

Actually, I believe the semantics of override are such that

    A override B override C 
  = (A override B override) C 
  = A override (B override C)

I don&apos;t have time or space to lay out the details here, but those
with member access to the W3C site can find further information 
in a series of emails to the archive, pointed to from

  http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2009Jan/0004.html

I notice there&apos;s a typo there, so I&apos;ll repeat the pointers here:

  http://lists.w3.org/Archives/Member/w3c-archive/2009Jan/0053.html
  http://lists.w3.org/Archives/Member/w3c-archive/2009Jan/0054.html
  http://lists.w3.org/Archives/Member/w3c-archive/2009Jan/0058.html

You will want to read those notes (at least the description of
the notation and a couple simple examples) before continuing.

In the notation developed there, the example you mention is

  A overrides B with E1
  B overrides C with E2

There are two cases:  E1 and E2 are disjoint, or overlap.

Either way, the formulaic notation provides this summary:

schema(A) = b + dir(A) + schema(over(E1,B))
          = b + dir(A) + b + dir(over(E1,B)) + schema(over(E1,over(E2,C)))
          = b + dir(A) + dir(over(E1,B)) + dir(over(E1,over(E2,C)))

If E1 and E2 are disjoint, it clearly doesn&apos;t matter if the two
sets of overrides to C are done in one sequence, or the other, or
at the same time.

If E1 and E2 overlap (let us assume each is a redefinition of an
element E), it matters that schema(A) includes version E1, not
version E2.

If we evaluate (A override B) first, we end up with the equivalent
of

  A include B&apos;
  B&apos; overrides C with E1

because the required transformation will override the E2 in the
override element in B.

If we evaluate (B override C) first, we end up with the equivalent
of

  A override B&apos; with E1
  B&apos; include C&apos;
  C&apos; = over(E2,C)

The transitive effect of the required transformation requires
that the override of B&apos; with E1 turn into both an override of the
declarations directly within B and an override of those in
C&apos;, because C&apos; is included by B.

</thetext>
  </long_desc><long_desc isprivate="0" >
    <commentid>24867</commentid>
    <comment_count>9</comment_count>
    <who name="John Arwe">johnarwe</who>
    <bug_when>2009-04-20 21:09:30 +0000</bug_when>
    <thetext>(In reply to comment #8)
&gt; (I find myself thinking of an old Doonesbury strip in which
&gt; Zonker asks Honey &quot;OK, which one of us is stoned this time?&quot;)

The effect, if not the cause, I can safely plead guilty to (first nice weekend since the trees started blooming).  I was intertwingling (you might recognize that, it&apos;s a technical term) it with the &quot;exactly one&quot; change for &lt;choice&gt;&apos;s Disjunction &amp;whatever.

&gt; I don&apos;t have time or space to lay out the details here, but those
 
I&apos;m glad you didn&apos;t spend time doing so, especially given comment #7 which likely crossed paths in the email stream.</thetext>
  </long_desc>
      
      

    </bug>

</bugzilla>