pyxbgen stop generation when SchemaUniquenessError exception is thrown
Brought to you by:
pabigot
Menu
▾
▴
2 Attachments
#169 pyxbgen stop generation when SchemaUniquenessError exception is thrown
closed
None
fixed
Generation Model
minor
PyXB 1.1.4
defect
2012-10-30
2012-10-26
No
Scenario:
root schema (root.xsd) containing includes as follows:
<xs:include schemaLocation="A.xsd">
<xs:include schemaLocation="B.xsd">
<xs:include schemaLocation="C.xsd">
Where A.xsd and B.xsd have the same signature.
Trying to generate bindings for root.xsd the following message is printed:
"INCLUDE B.xsd caught: "
And include C.xsd is not processed.
Attached a patch to ignore the pyxb.SchemaUniquenessError exception and allow further processing of include elements.
Discussion
Can you provide a reproducing case? The likelihood of two schema having the same signature but different content is supposed to be vanishingly small, and I believe the error is appropriate if the content is identical.
Example attached.
Consider the following:
base.xsd defines some common elements that are used all over the schema, so a.xsd, b.xsd and c.xsd include it.
a.xsd and b.xsd do not define additional elements (maybe they will do it in the future) so the signature is identical:
0f46ae081827e9d64369fbc1b2b0aa2b c.xsd
17b91eaa352e89f9f6ba6dce962449e2 root.xsd
c7197fe331f11f287f816a0695a92d86 base.xsd
ea91a6e0d812df5fdcd25e079f6f648e a.xsd
ea91a6e0d812df5fdcd25e079f6f648e b.xsd
Thus, pyxbgen starts processing root.xsd and stop the generation when b.xsd "duplicity" is detected, so c.xsd is not processed and not included in the binding:
[tmp]$ pyxbgen --schema-location=xsd_example/root.xsd --binding-root=. --module=myschema
urn:uuid:26832c88-21ab-11e2-8d88-101f74343361
Schema at /tmp/xsd_example/b.xsd already registered in AbsentNamespace0
INCLUDE /tmp/xsd_example/b.xsd caught:
WARNING: Skipped redundant translation of /tmp/xsd_example/b.xsd defining AbsentNamespace0
Python for AbsentNamespace0 requires 1 modules
Saved binding source to ./myschema.py
Thanks. I agree PyXB can legitimately continue on in this case. However instead of ignoring the diagnostic I'll probably make it emit a warning that it did not read the apparently redundant schema a second time, unless I can verify that the full text (not just the hash) is the same. (This is necessary because when a new information item is added, PyXB does not analyze the item check to see if it is identical to an existing item with the same name, which would be legal; instead it assumes it is different, which is not legal. Thus including the same document twice, while technically legal in XML Schema, would cause PyXB to fail.)
Fixed in pyxb-1.1/next branch: