[ http://nagoya.apache.org/jira/browse/XERCESJ-1032?page=history ]
Lucian Holland updated XERCESJ-1032:
------------------------------------
Attachment: patch.txt
I've moved the sorting so that it happens in XSConstraints itself, and it now
covers a lot more of the edge cases!. Not sure what sort of effect this will
have on performance - I didn't see any obvious slowdown, but I haven't measured
it properly.
> 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, 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]
