SF/229: xsd.QName is not correct #13

pabigot opened this Issue Jun 6, 2014 · 0 comments


None yet

1 participant

pabigot commented Jun 6, 2014


The value space is namespace/localname pairs; the lexical space is prefix:localname. Need to inherit from pyxb.namespace.ExpandedName instead of text_type.

This is a blocker because the namespace contexts required to support it are not available. This relates to #12, and is best fixed by a major overhaul that refactors PyXB to closely follow XML infosets.

See also original mail thread.

@pabigot pabigot added the sourceforge label Jun 6, 2014
@pabigot pabigot added this to the PyXB 1.2.4 milestone Jun 6, 2014
@pabigot pabigot added a commit that referenced this issue Jun 12, 2014
@pabigot domutils: accept binding instances for text and attribute values
When issue #13 is fixed use of xsdLiteral() will fail to preserve the
information necessary to reconstruct all simple types: in particular
QName representations as XML text require a namespace declaration to be
in scope.  Instead of having the caller do the conversion to text, do it
down in the BDS infrastructure which knows how to handle this situation.
@pabigot pabigot added a commit that closed this issue Jun 12, 2014
@pabigot fix #13: SF/229: xsd.QName is not correct
Rebase xsd.QName as an extension of pyxb.namespace.ExpandedName rather
than a unicode string.  Provide a mechanism for recording the current
namespace context so this need not be passed through deep and wide
callchains to reach the QName constructor where it is required.

Since a QName cannot be represented as unicode text in the absence of
namespace declarations, enumeration registrations (which may be QNames)
must now support non-unicode values.  This also means that bindings may
register namespaces for which no content information is available.

Note that consequently attributes and elements that are QNames are
converted when they are processed, and post-process interpretation is no
longer appropriate.  This mostly affects examples in PyXB but is likely
to bite WSDL and related applications that leverage QNames.

This commit has more asserts than are appropriate for a release; they
are present to help detect unimagined dependencies.

Also note: The change in representation requires that bindings must be
regenerated if they include QName values for attributes or elements.
This particularly applies to OpenGIS.
@pabigot pabigot closed this in eb61be9 Jun 12, 2014
@pabigot pabigot added a commit that referenced this issue Jun 12, 2014
@pabigot fix #14: SF/233: wildcard attributes not generated
We'll also officially support the semi-public _setAttribute method for
this capability, so this closes #11: SF/227: inadequate support for
wildcard attributes.

And the test verifies that the fix for issue #13 implicitly closes #12:
SF/228: add namespace declarations for wildcard content.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment