[ http://nagoya.apache.org/jira/browse/XERCESJ-1032?page=comments#action_56091 ] Lucian Holland commented on XERCESJ-1032: -----------------------------------------
Aaargh. Ignore my patch - it only works in some cases (and embarrassingly, not in the case of the file I submitted - that's what comes of paring down your examples and then not retesting them!). I will make another patch that does the ordering in XSConstraints rather than in the SGHandler...Sorry! > Bizarre interaction between choice restrictions and substitutionGroups > ---------------------------------------------------------------------- > > Key: XERCESJ-1032 > URL: http://nagoya.apache.org/jira/browse/XERCESJ-1032 > Project: Xerces2-J > Type: Bug > Components: XML Schema Structures > Versions: 2.6.2 > Environment: java 1.4 on linux > Reporter: Lucian Holland > Attachments: patch.txt, test1.xsd > > You've probably seen this one before, but there's a really wacky interaction > between the way substitutionGroups work and how choice restrictions are > specified. The particular oddness that I'm looking at results from the > combination of three rules from the schema spec: > 1) substitutionGroups are supposed to be expanded into choices prior to > checking the validity of a restriction > 2) When validating that a choice particle is a valid restriction of another > choice particle, MapAndSum specifies an *order-preserving* mapping between > the particles of the base and the restriction > 3) The order of the particles in the generated choice for a substitutionGroup > is nowhere specified. > As a consequence, if you have an element Er in a restricting type R of a base > type B, corresponding to an element Eb in the base type, then you run into > difficulties if Er is in the substitutionGroup of Eb and there is at least > one element in the substitutionGroup of Er. (See the attached schema for an > example) Basically what you end up with is two choice groups of undefined > ordering, one of which is supposed to be a restriction of the other. > Currently, the ordering that Xerces applies is a haphazard product of the way > that loop iterations are conducted in the SubstitutionGroupHandler and > XSContraints; as a result, schemas of this nature are almost always marked > as invalid due to a MapAndSum error. > Given that the validity of such schemas is left open by the schema spec due > to its silence on the ordering of the generated choices, and the fact that > the schemas in question are "obviously valid" to a human reader, I would like > to propose a patch that ensures that substitutionGroups always have a defined > ordering (I picked an ordering on namespace, then localname, but it isn't > really important provided that it's consistent). The patch means that Xerces > reports schemas of the form described above as valid; given that all > substitutionGroups are now consistently ordered, I don't see that this could > have any negative side-effects from the point of view of validation. The only > potential downsides are the performance of using a TreeSet rather than a > Vector (I have done some very unscientific testing on some pretty large > schemas with very heavy use of substituionGroups, and I couldn't see any > measurable difference) and the fact that it obviously changes the ordering > reported for the elements in a substitutionGroup by the XSModel (but I don't > see this as particularly significant since I believe the ordering would > already have been non-deterministic for subGroups that spanned multiple > grammars - the grammar bucket is based around a HashTable) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://nagoya.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
