Just because a namespace is default within a schema doesn't mean it has
to be default in documents that use components from that schema. Also,
it may not be a good thing to use the namespace of the top-level element
as the default when generating documents from an instance; if most of
the interesting elements are in a different namespace (as often happens
with SOAP messages), that namespace would be a better selection as default.
If multiple namespaces are being used and I wanted something more
informative than "ns1", I'd probably use the customization feature or a
library initialization routine to declare in the global BDS a default
preferred prefix for each namespace, and not configure a default
namespace at all. Unless configured through
BindingDOMSupport.SetDefaultNamespace, the generated documents have no
default namespace. Perhaps an alternative enhancement would be to have
a global flag that uses the namespace of the top-level element as the
default in this situation. That's an enhancement I could see adding.
Or, use the name of the module into which the namespace bindings were
generated as the default prefix for that namespace (in fact there're
hooks in PyXB for that sort of thing, and I can't remember why I've
added and then removed the feature several times).
What happens when no bds instance is provided in a toxml() call is that
a new one is created, initialized from the global defaults, used for the
entire tree, then discarded. This is necessary because the
namespace/prefix map in the instance is updated based on the namespaces
encountered when walking the instance tree. If these instances were
re-used, you could get a bunch of namespace declarations that weren't
relevant to the particular document. Trying to configure per-namespace
defaults that handle multi-namespace documents could get very confusing.
At the moment, I'm not convinced a per-namespace default BDS
configuration would be a good thing, but if you still think it would be
useful, yes, please file an enhancement request in trac. Include the
details on these use cases, and any preferences you have on the
interface and semantics, especially in cases where instance objects that
reference multiple namespaces are concerned. For example, it would be
legal to add a new default namespace declaration at each element where
it changes, which is perhaps more consistent with the "different default
namespace per schema" perspective.
<?xml version="1.0" ?>
<Container xmlns="urn:Container:1.0" xmlns:cdb="urn:CDB:1.0">
<Autoload>
<_ string="baci" xmlns="urn:CDB:1.0"/>
</Autoload>
<LoggingConfig centralizedLogger="Log" dispatchPacketSize="0"
immediateDispatchLevel="99" minLogLevel="2"/>
</Container>
Peter
Arne Grimstrup wrote:
> Hi Peter,
>
> On Wed, Nov 25, 2009 at 3:01 PM, Peter A. Bigot <[email protected]
> <mailto:[email protected]>> wrote:
>
> I can't think of a way to do that restricted to specific
> namespaces, but it might be a worthwhile enhancement. You can set
> global defaults:
>
>
> pyxb.utils.domutils.BindingDOMSupport.SetDefaultNamespace(container.Namespace,)
> pyxb.utils.domutils.BindingDOMSupport.DeclareNamespace(cdb.Namespace,
> 'cdb')
>
> which should produce the output you want, assuming that the
> bindings for the relevant namespaces are imported as modules
> called container and cdb. Whether this might impact your users'
> desires for a different default namespace is something to
> consider; you might want to provide a default declaration for your
> default namespace in case the user overrides it and a prefix is
> required.
>
>
> http://pyxb.sourceforge.net/userref_usebind.html#creating-xml-documents-from-binding-instances
>
> Peter
>
>
> I thought about setting the globals as described in the link. While
> that would work for this particular case, I can envision a situation
> where a user might be working with several schemata, each having its
> own default namespace. I think setting globals in that case would
> create confusion and more trouble.
>
> Should I file a ticket in Trac about this enhancement?
>
> Regards,
>
> Arne
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now. http://p.sf.net/sfu/bobj-july
> ------------------------------------------------------------------------
>
> _______________________________________________
> pyxb-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/pyxb-users
>
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
pyxb-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pyxb-users
