You've specified that all three schema are in the same namespace: are you
declaring that namespace in each, or are you using a chameleon schema model
where A.xsd has no namespace, and consequently gets assigned one by the fact
of its inclusion into B and C? What bothers you about using a gathering
schema that makes explicit the fact that A, B, and C all describe the same
namespace?
It might be possible to do what you're asking, but I don't believe it would
be a good thing. Inclusion in XMLSchema, Python, and C++ are slightly
different. Taking the old C distinction between definition (memory is
allocated for either code or data) and declaration (if you can find the
memory, here's what it will look like):
* In XMLSchema, the schema *defines* elements and types that are available
in the targetNamespace. A schema that defines a complex type Foo, when
included into different namespaces, produces distinct Foo objects.
* In Python, a module *defines* elements and types. A module that defines a
class Foo, when imported into different modules, produces multiple
references to the same Foo class.
* In C++, a header *declares* elements and types. A header that declares a
class Foo, when included into different modules, allows creation of
distinct Foo objects that share the same class.
In other words, Python doesn't have an "include" in the same sense as C++
and XMLSchema, but does have "import" in the same sense as XMLSchema.
"include" in C++ and XMLSchema is a preprocessing step. "import" in Python
and XMLSchema is a linking step. Combining them may be possible in specific
cases, but not in general.
When B and C are being scanned to characterize their elements and types, the
content of A must be available, and there is a mutual dependency: the code
generated for A can explicitly depend on material from its including
environment. Consider a case where B and C both define their own concept of
a complex type "Base", and A extends with a definition for "Sub". PyXB
expects to have the definition for "Base" available at the time the code for
"Sub" is generated. Even if at the end it is able to make the "Sub" class
inherit from the "Base" definition, it does so with implicit and sometimes
explicit reference to fields and data stored in the Base class, such as
references to the classes that can be accepted as content within instances
of the "Sub" class.
The whole concept of chameleon schema relies on the fact that including A
into B and C allows for a situation where A.Sub in B's context is different
from A.Sub in C's context. Placing A into a Python module in its own right
doesn't allow that to occur correctly.
This chameleon nature is true even if A, B, and C all share the same
explicit namespace, since the value of {myURI}Sub derived from B including A
and the value of {myURI}Sub derived from C including A depend on where you
interpret the namespace "myURI". PyXB's fundamental assumption of "one
namespace, one module" means that such a distinction can't be represented in
a single Python program: distinct uses belong in distinct modules, which
require distinct namespaces.
If you like, please file a ticket requesting this feature, and providing an
use case that explains why it's necessary. If the use case is compelling,
I'll reconsider. If I've convinced you and (or) you don't think it worth
writing the ticket, I'll do a summary for tracking purposes and add this
analysis for the record.
Peter
On Tue, 12 Jan 2010, Romain CHANU wrote:
> Yes, I have thought about this solution but it would be my "backup"
> solution.
>
> In C++, CodeSynthesis XSD creates a header file A.hpp containing the types
> defined in A.xsd. This header file is then included in the other header
> files (B.hpp, C.hpp). There is no problem like described before since the
> #include guards prevent from double inclusion.
>
> Would it be possible to do that in PyXB?
>
> Cheers,
>
> Romain
>
> 2010/1/12 <p...@dakotacom.net>
>
>> The best way to deal with this is to create a single schema that just
>> includes both B.xsd and C.xsd, and generate the bindings using it. A.xsd
>> will come along for the ride. Since B and C represent objects in the same
>> namespace, they really need to be generated into a single Python module,
>> and
>> PyXB expects a one-to-one namespace/module correspondence. The tool
>> doesn't
>> directly provide a way to merge schema without a helper schema like this.
>>
>> Though there are situations where two schema in the same namespace can be
>> inconsistent with each other, that's not a wise practice, and presumably
>> doesn't arise here because then it would be inconsistent to use both in the
>> same Python program too.
>>
>> Peter
>>
>>
>> On Tue, 12 Jan 2010, Romain CHANU wrote:
>>
>>> Hi,
>>>
>>> Let's say we have three XML schemas: A.xsd, B.xsd, C.xsd. A.xsd is
>>> included
>>> (with the include directive) in B.xsd and also in C.xsd
>>>
>>> I generate the bindings for B and C. I got two Python files B.py and C.py
>>>
>>> If I import "B" and "C" in the same Python file, it will result in an
>>> error
>>> saying that some types (those defined in A.xsd) have multiple definitions
>>> (note that i am using the same namespace in the three schemas).
>>>
>>> Is there a way to handle this situation?
>>>
>>> Thank you for your help.
>>>
>>> Cheers,
>>>
>>> Romain
>>>
>>>
>>
>
--
Peter A. Bigot E-mail: big...@acm.org
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
pyxb-users mailing list
pyxb-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/pyxb-users
