[xsd-users] Issue with includes

[Boris Kolpackov]

Hi Patrick,

Patrick Shinpaugh <shpatric at vt.edu> writes:

> I am trying to use xsd to create data binding for the x3d schema
> ( http://www.web3d.org/x3d/specifications/ ) - the 3 .xsd files. I have
> validated the schema using the w3c validator which gives the warnings
> about anyType.

I downloaded the schemas and tried to compile x3d-3.0.xsd. I got the
following error:

error: Complex type 'X3DAppearanceNode' violates the Unique Particle
Attribution rule in its components 'ProtoInstance' and 'ProtoInstance'

Did you manage to resolve this?


> As such, it appears that your program handles includes
> differently than perhaps it should - validating each file separately
> instead of as a whole.

Right. XSD tries to preserve the modularity of your schemas in the
generated code by mapping xsd:includes (and xsd:imports) to the C
preprocessor #include directives. As a result of this mapping, XSD
requires that the included schema files be self-sufficient which is
not required by the XML Schema spec as you correctly pointed out.
This is the first real-world schema where we run into this issue.


> Below is the output I get. If I remove the includes then the data
> binding will succeed (without the extensions which we also need) and
> the anyType variables are handled nicely.
>
> Is there an option to change the way includes are handled?

There is no such option at the moment. One way to address this would
be to provide an option to generate code for included schemas inline
instead of generating #include directives. We may implement this
option in the future versions of XSD.

Meantime I can suggest a couple of workarounds:

1. XSD can handle cyclic inclusion if the types in the two schemas
   do not inherit from each other (e.g., type D from schema d.xsd
   inherits from type B from schema b.xsd and both b.xsd and d.xsd
   include each other). So the first thing to try it to xsd:include
   x3d-3.0.xsd in x3d-3.0-Web3dExtensionsPrivate.xsd  and/or
   x3d-3.0-Web3dExtensionsPublic.xsd and see of the generated code
   compiles. I do not know what you have in your extension schemas
   so I cannot say whether this will work or not.

2. The second approach is to still add inclusion of x3d-3.0.xsd in
   x3d-3.0-Web3dExtensionsPrivate.xsd  and/or
   x3d-3.0-Web3dExtensionsPublic.xsd but break the cycle by removing
   inclusions from x3d-3.0.xsd. You can also rename the modified
   x3d-3.0.xsd to something like x3d-3.0-base.xsd and create a new
   x3d-3.0.xsd which will include all three other schemas. In other
   words, you include graph will look like this:

   x3d-3.0-base.xsd
   x3d-3.0-Web3dExtensionsPublic.xsd includes x3d-3.0-base.xsd
   x3d-3.0-Web3dExtensionsPrivate.xsd includes x3d-3.0-base.xsd
   x3d-3.0.xsd: includes x3d-3.0-base.xsd, x3d-3.0-Web3dExtensionsPublic.xsd,
     and x3d-3.0-Web3dExtensionsPrivate.xsd

   This method will work no matter what you have in your schemas and will
   result in the schema equivalent to the original (e.g., it will validate
   exactly the same set of documents).

Please let me know if this works for you.


-boris

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: Digital signature
Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20060928/5189c0f4/attachment.pgp