[xsd-users] Issue with includes

[Patrick Shinpaugh]

Hi Boris,
You must have downloaded the zip archive - unfortunately it is from 2004
whereas the individual .xsd files on that page are from early 2006.

I will give the workarounds you suggested a try when I get a chance
sometime next week. They do sound promising - I'll let you know.

Thanks,
Patrick


On Thu, 2006-09-28 at 13:19, Boris Kolpackov wrote:
> 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
> 
> 
> ______________________________________________________________________
> _______________________________________________
> xsd-users mailing list
> xsd-users at codesynthesis.com
> http://codesynthesis.com/mailman/listinfo/xsd-users
-- 
Patrick Shinpaugh
Virginia Tech
UVAG System Administrator/Programmer
540-231-2054