<xs:all/> is never used to represent interleaves

[GoogleCodeExporter]

What steps will reproduce the problem?
1. convert (elem1 & elem2?) to xsd

What is the expected output? What do you see instead?
You should expect to see an <xs:all/> accurately represent this construct, but 
instead you get an <xs:choice/>, which is only necessary as a fall-back when 
the interleave contains elements with zero-or-more or one-or-more cardinalities.

What version of the product are you using? On what operating system?
The latest source code from subversion, as of 9th of November, 2010

Please provide any additional information below.
I've looked at the earliest revisions of the code available online, and it 
seems to me that this could not have worked since 2002, although there is code 
that attempts to do this properly.

Additionally, I believe the correct behaviour would also be to emit a warning 
when <xs:choice/> has to be used, since this is only an approximation of the 
RNG schema -- I used this message in my fix:

  complex-interleave=cannot represent interleave containing zero-or-more or one-or-more cardinalities; approximating

Original issue reported on code.google.com by dominic....@gmail.com on 10 Nov 2010 at 11:37

Attachments:

• Transformer.java

[GoogleCodeExporter]

Also attaching the RNC I used to test my fix

Original comment by dominic....@gmail.com on 10 Nov 2010 at 11:39

Attachments:

• interleave.rnc

[GoogleCodeExporter]

Same bug here.  Thanks so much for taking the time to write up the bug and 
offer a fix for this unfortunate bug.  Now I just have to re-learn Java to 
actually get your fix working for me, but things could certainly be worse!

Original comment by ladene...@gmail.com on 12 Jul 2011 at 3:22

[GoogleCodeExporter]

Unfortunately, I'm not sure if this patch worked in all cases. IIRC, there is a 
restriction in XMLSchema where in certain circumstance the <xs:all/> tag is 
invalid. I think it was something like that, though it's now a bit hazy to me 
know, and I can't remember if we're using this code and I changed our schemas 
to avoid this corner case, or if I found some other way to work round the 
problem.

RNC is truly great if you use jing to validate directly, but converting complex 
schemas with trang creates numerous problems you have to work around if your 
schemas are too complex. Real shame!

Original comment by dominic....@gmail.com on 12 Jul 2011 at 11:54

[GoogleCodeExporter]

Your patch does improve the situation.  I'm now at least able to use 
interleaving in some situations.  You're right though that RNC just doesn't 
seem to be the right choice if conversions are necessary.

Humorously, it turns out that OxygenXML has the same bug.  Apparently they use 
trang for their schema conversion as well, heh.

Original comment by ladene...@gmail.com on 12 Jul 2011 at 4:12