- From: Kevin Braun <kbraun@obj-sys.com>
- Date: Mon, 05 Oct 2009 13:28:12 -0400
- To: "C. M. Sperberg-McQueen" <cmsmcq@blackmesatech.com>
- CC: www-xml-schema-comments@w3.org
Unless I misunderstand it, the change to 3.8.6.3 is entirely about conditional type assignment, and not at all about dynamic EDC, while the way I read the change list implies that it is entirely about dynamic EDC. I see I misread the change list on "Validation rules for conditional types", so disregard my comment on that. So then, I would recommend something along the following lines (I may not have it quite right, but hopefully it illustrates what I'm getting at). Replace: "The constraint Element Declarations Consistent (§3.8.6.3) has been revised to require more consistency in type assignment when elements with the same expanded name may match both a local element declaration and a wildcard in the same content model. XSD 1.0 allows such content models even if there is a discrepancy between the type assigned to elements by the local element declarations and by the top-level element declaration which will govern elements which match the wildcard. For compatibility reasons, such content models are still allowed, but any element instance which matches the wildcard is required to have a governing type definition compatible with the type assigned by the local element declarations matched by the element's expanded name." with something along the lines of: "The constraint Locally Valid (Complex Type) (§3.4.4.2) <http://www.w3.org/TR/xmlschema11-1/#cvc-complex-type> has been revised to require type assignment consistency. XSD 1.0 allows content models where elements with the same expanded name may match both a local element declaration and a wildcard in the same content model, even if there is a discrepancy between the type assigned to elements by the local element declarations and by the top-level element declaration which will govern elements which match the wildcard. For compatibility reasons, such content models are still allowed. However, Element Locally Valid (Complex Type) (§3.4.4.2) now requires that any element instance which matches the wildcard (at validation time) has a governing type definition compatible with the type assigned by the local element declarations matched by the element's expanded name. And then before the following bullet point: "Validation rules for conditional types: a validation-time check on restrictions of complex types ensures that the conditionally assigned types of their children are appropriately related to the types assigned by their base type; see Element Locally Valid (Complex Type) (§3.4.4.2) <http://www.w3.org/TR/xmlschema11-1/#cvc-complex-type> and Conditional Type Substitutable (§3.4.4.5) <http://www.w3.org/TR/xmlschema11-1/#vr-cta-substitutable>; the definition of ·governing type definition· <http://www.w3.org/TR/xmlschema11-1/#key-governing-type-elem> is also adjusted" add a bullet point similar to this one: "The constraint Element Declarations Consistent (§3.8.6.3) <http://www.w3.org/TR/xmlschema11-1/#cvc-complex-type> has been modified to help ensure type consistency in a model group among the type tables of local element declarations and those global element declarations of the same expanded name which may be attributed to either wildcards or open content in the model group." HTH, Kevin On 10/2/2009 10:27 PM, C. M. Sperberg-McQueen wrote: > On 1 Oct 2009, at 13:32 , bugzilla@wiggum.w3.org wrote: > >> http://www.w3.org/Bugs/Public/show_bug.cgi?id=7787 >> >> Summary: Description of change to Element Declarations >> Consistent >> is confusing >> Product: XML Schema >> Version: 1.1 only >> Platform: PC >> OS/Version: Windows XP >> Status: NEW >> Severity: normal >> Priority: P2 >> Component: Structures: XSD Part 1 >> AssignedTo: David_E3@VERIFONE.com >> ReportedBy: kbraun@obj-sys.com >> QAContact: www-xml-schema-comments@w3.org >> CC: cmsmcq@blackmesatech.com >> >> >> In the "changes since 1.0", we have the following description: >> >> "The constraint Element Declarations Consistent (§3.8.6.3) has been >> revised to >> require more consistency in type assignment when elements with the same >> expanded name may match both a local element declaration and a >> wildcard in the >> same content model. XSD 1.0 allows such content models even if there >> is a >> discrepancy between the type assigned to elements by the local element >> declarations and by the top-level element declaration which will govern >> elements which match the wildcard. For compatibility reasons, such >> content >> models are still allowed, but any element instance which matches the >> wildcard >> is required to have a governing type definition compatible with the type >> assigned by the local element declarations matched by the element's >> expanded >> name." >> >> This seems misleading to me. From what I can tell, the "is required" >> of the >> last sentence is not part of 3.8.6.3 (as implied), but is handled by >> step 5 of >> 3.4.4.2 Element Locally Valid (Complex Type) (which I discovered >> thanks to the >> discussion in bug 5940). > > The description attempts to record what seemed to the editor > who drafted it the salient part of the change and the salient > motivations for it. The key concept in the change described > here is the introduction of what the WG informally called at > the time "dynamic EDC". As you observe, the realization of > dynamic EDC required changes to several other locations which > define concepts appealed to directly and indirectly from the > EDC rule. > > If you find the characterization misleading or unhelpful, then > I regret that shortcoming in the description. But in the final > analysis, when drafting the description of changes I call 'em > as I see 'em. > >> The change to 3.8.6.3 seems to focus on type consistency when >> conditional type >> assignment is being used, but you'd never get that from the >> discussion above. > > There is plenty of mechanism related to conditional type assignment > in 3.8.6.3, but it was introduced not as part of the shift to > dynamic EDC but as part of the introduction of conditional type > assignment. > >> 3.4.4.2 Element Locally Valid (Complex Type) is mentioned in the >> "changes >> since" appendix when discussing validation rules for conditional >> types, while >> 3.8.6.3 Element Declarations Consistent isn't mentioned. Isn't that >> somewhat >> backwards? 3.8.6.3 seems to be specifically targeted to conditional >> types, >> while 3.4.4.2 aims for a more general type consistency. > > I won't claim to remember the exact thought processes that > gave rise to the wording now in the document, but since > 3.8.6.3 contains a static constraint on schemas, not a validation > rule, I would find it strange if it were mentioned in a > paragraph about changes to validation rules. It may well be > that other observers drafting a list of changes would choose > to set different accents. If you want a characterization > of changes that does not depend on any individual's judgement, > then you probably want to consult the diffed version with > changes since 1.0. It is not devoid of judgement calls, but > they are less obtrusive. > > I hope this helps, but I don't see any obvious way to revise > any of the text you have commented on here so as to improve > things. >
Received on Monday, 5 October 2009 17:30:16 UTC