RE: Substitution Groups and NonDeterminism

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