- From: Mark Feblowitz <mfeblowitz@frictionless.com>
- Date: Mon, 10 Dec 2001 10:36:15 -0500
- To: "'Jeni Tennison'" <jeni@jenitennison.com>
- Cc: "Xmlschema-Dev (E-mail)" <xmlschema-dev@w3.org>
Thanks - That helps a lot. I found out that I had another issue, too: that I had added an item from ns2 to the substitution group in ns1 and that, further down, I had an any ##other element that also matched the item in the substitution group. And it looks like the solution is the same - make sure that there's required (and different) content in between. A small sacrifice in the name of determinism(!). And it's great to have a validator like XSV to show me the error(s) of my ways. Thanks again, Mark ---------------------------------------------------------------------------- ---- Mark Feblowitz [t] 617.715.7231 Frictionless Commerce Incorporated [f] 617.495.0188 XML Architect [e] mfeblowitz@frictionless.com 400 Technology Square, 9th Floor Cambridge, MA 02139 www.frictionless.com -----Original Message----- From: Jeni Tennison [mailto:jeni@jenitennison.com] Sent: Monday, December 10, 2001 7:10 AM To: Mark Feblowitz Cc: Xmlschema-Dev (E-mail) Subject: Re: Substitution Groups and NonDeterminism Hi Mark, > Am I correct that, if I have a Substitution Group as element content > that I cannot place any of its members as succeeding siblings > without triggering a nondeterminism? Is there a way around this > (that doesn't force the succeeding sibling down into some further > nested content)? It's not *quite* as general as that. The reason that you have non-determinism in your case is because (a) the choice from the substitution group is repeated any number of times and (b) the AttachmentReference element is optional. If the AttachmentReference weren't optional, the validator would know that anything before the AttachmentReference was from the choice arising from the substitution group, and anything after should be the ShipToPartner element. So one option would be to make the AttachmentReference element required. If it sometimes doesn't hold any information (which is presumably why it's optional) then you should make it nillable so that you can have: ... <Partner>...</Partner> <AttachmentReference xsi:nil="true" /> <ShipToPartner>...</ShipToPartner> ... when the content of the AttachmentReference element doesn't matter. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/
Received on Monday, 10 December 2001 10:36:52 UTC