pyxb-users Mailing List for PyXB: Python XML Schema Bindings (Page 5)
Brought to you by:
pabigot
You can subscribe to this list here.
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
(3) |
Oct
|
Nov
(11) |
Dec
(17) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
(17) |
Feb
(3) |
Mar
|
Apr
|
May
(7) |
Jun
(1) |
Jul
(7) |
Aug
(3) |
Sep
|
Oct
(7) |
Nov
(4) |
Dec
(2) |
2011 |
Jan
(3) |
Feb
(4) |
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(14) |
Nov
|
Dec
|
2012 |
Jan
(8) |
Feb
(7) |
Mar
(5) |
Apr
(5) |
May
(16) |
Jun
(5) |
Jul
(3) |
Aug
(2) |
Sep
|
Oct
|
Nov
(3) |
Dec
(1) |
2013 |
Jan
(4) |
Feb
(9) |
Mar
(8) |
Apr
(5) |
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
(5) |
Oct
(9) |
Nov
(2) |
Dec
|
2014 |
Jan
|
Feb
(19) |
Mar
(4) |
Apr
(3) |
May
(3) |
Jun
(1) |
Jul
|
Aug
(3) |
Sep
|
Oct
(3) |
Nov
|
Dec
(3) |
2015 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
(10) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
(1) |
2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2017 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Vladimir T. <ins...@gm...> - 2013-02-28 10:16:17
|
Hi, I have three master schemas that I have to use to deserialize the objects. My question is: Is it possible to combine these schemas in one object so I can use that object to deserialize all types of objects. In JAXB I can define a Context that includes several namespaces and I can use that Context to deserialize all types of objects. But with pyxb I have several files that I need to import and use them separately to deserialize different objects. I could have something like: import master1, master2 try: return master1.CreateFromDOM(domutils.StringToDOM(r)) except: try: return master2.CreateFromDOM(domutils.StringToDOM(r)) except: return None But I was wondering if I can just put everything in one big py file, import it and use it. Currently I run pyxbgen once to generate everything and I put my master schemas first in the parameter list and then the rest of the schemas (-u <path> -m <module>). The command generates several modules starting with _ and three other modules that start with a character (not _) - these three I need to import and use. Should I define my own schema that includes the three master schemas and generate the bindings again to achieve what I need? Regards, Vladimir |
From: Peter B. <bi...@ac...> - 2013-02-27 20:23:44
|
The actual fix was slightly different but has the same effect on the bindings as what I recommended below. Details in the trac ticket. Peter On Wed, Feb 27, 2013 at 12:47 PM, Peter Bigot <bi...@ac...> wrote: > I've replicated this as http://sourceforge.net/apps/trac/pyxb/ticket/191 > > In pyxb/binding/basis.py add 'Namespace' to the _ReservedSymbols set in > the complexTypeDefinition class. > > As a consequence, the attribute "Namespace" will be spelled "Namespace_" > in the bindings, but that's consistent with how PyXB handles other XML > attribute/element names that conflict with identifiers reserved by either > Python or PyXB. > > Peter > > On Wed, Feb 27, 2013 at 10:55 AM, Vladimir Todorov <ins...@gm...>wrote: > >> Actually the global Namespace should not be overriden by the local >> declaration because it is local to the class - the code below the local >> declaration should use the global Namespace instead of the local Namespace >> One thing that comes to my mind is to have this in the bindings: >> >> ... >> globalNamespace = Namespace >> Namespace = property(__Namespace.value, __Namespace.set, None, >> u'none\nThe namespace of the API definition.\n false') >> >> and everything below that uses >> pyxb.namespace.ExpandedName(Namespace, ..) >> should be >> pyxb.namespace.ExpandedName(globalNamespace, ..) >> >> but I will have to change everything by hand and if I regenerate the >> schemas I will need to do it again. >> >> >> >> On Wed, Feb 27, 2013 at 6:26 PM, Vladimir Todorov <ins...@gm...>wrote: >> >>> Hi all, >>> >>> Today I hit a problem while I was trying to import the generated >>> bindings for a particular schema. After some debugging I found out that the >>> problem is actually with the schema - it defines a property called >>> "Namespace" (yep ..) and in the generated code there is something like >>> this: >>> >>> Namespace = property(__Namespace.value, __Namespace.set, None, >>> u'none\nThe namespace of the API definition.\n false') >>> >>> Now this is a problem because Namespace is expected to be of type >>> 'Namespace' but now it is of type 'property': >>> >>> File >>> "/usr/local/lib/python2.6/dist-packages/pyxb/namespace/__init__.py", line >>> 183, in __init__ >>> raise pyxb.LogicError('ExpandedName must include a valid (perhaps >>> absent) namespace, or None.') >>> >>> >>> On line 183 in this file we have: >>> >>> if (ns is not None) and not isinstance(ns, Namespace): >>> raise pyxb.LogicError('ExpandedName must include a valid >>> (perhaps absent) namespace, or None.') >>> >>> 'ns' will be of type 'property' because of the code above. >>> >>> >>> The 'Namespace' property overrides the 'Namespace' variable defined in >>> the beginning of the generated bindings: >>> Namespace = pyxb.namespace.NamespaceForURI(...) >>> >>> pyxbgen --version >>> pyxbgen from PyXB 1.1.4 >>> >>> Unfortunately I cannot modify the schemas because I am not the owner. >>> Does anyone know how I can fix this (easy way)? It is extremely >>> important for me. >>> >>> Regards, >>> Vladimir >>> >> >> >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> _______________________________________________ >> pyxb-users mailing list >> pyx...@li... >> https://lists.sourceforge.net/lists/listinfo/pyxb-users >> >> > |
From: Peter B. <bi...@ac...> - 2013-02-27 18:49:04
|
I've replicated this as http://sourceforge.net/apps/trac/pyxb/ticket/191 In pyxb/binding/basis.py add 'Namespace' to the _ReservedSymbols set in the complexTypeDefinition class. As a consequence, the attribute "Namespace" will be spelled "Namespace_" in the bindings, but that's consistent with how PyXB handles other XML attribute/element names that conflict with identifiers reserved by either Python or PyXB. Peter On Wed, Feb 27, 2013 at 10:55 AM, Vladimir Todorov <ins...@gm...>wrote: > Actually the global Namespace should not be overriden by the local > declaration because it is local to the class - the code below the local > declaration should use the global Namespace instead of the local Namespace > One thing that comes to my mind is to have this in the bindings: > > ... > globalNamespace = Namespace > Namespace = property(__Namespace.value, __Namespace.set, None, u'none\nThe > namespace of the API definition.\n false') > > and everything below that uses > pyxb.namespace.ExpandedName(Namespace, ..) > should be > pyxb.namespace.ExpandedName(globalNamespace, ..) > > but I will have to change everything by hand and if I regenerate the > schemas I will need to do it again. > > > > On Wed, Feb 27, 2013 at 6:26 PM, Vladimir Todorov <ins...@gm...>wrote: > >> Hi all, >> >> Today I hit a problem while I was trying to import the generated bindings >> for a particular schema. After some debugging I found out that the problem >> is actually with the schema - it defines a property called "Namespace" (yep >> ..) and in the generated code there is something like this: >> >> Namespace = property(__Namespace.value, __Namespace.set, None, >> u'none\nThe namespace of the API definition.\n false') >> >> Now this is a problem because Namespace is expected to be of type >> 'Namespace' but now it is of type 'property': >> >> File >> "/usr/local/lib/python2.6/dist-packages/pyxb/namespace/__init__.py", line >> 183, in __init__ >> raise pyxb.LogicError('ExpandedName must include a valid (perhaps >> absent) namespace, or None.') >> >> >> On line 183 in this file we have: >> >> if (ns is not None) and not isinstance(ns, Namespace): >> raise pyxb.LogicError('ExpandedName must include a valid >> (perhaps absent) namespace, or None.') >> >> 'ns' will be of type 'property' because of the code above. >> >> >> The 'Namespace' property overrides the 'Namespace' variable defined in >> the beginning of the generated bindings: >> Namespace = pyxb.namespace.NamespaceForURI(...) >> >> pyxbgen --version >> pyxbgen from PyXB 1.1.4 >> >> Unfortunately I cannot modify the schemas because I am not the owner. >> Does anyone know how I can fix this (easy way)? It is extremely important >> for me. >> >> Regards, >> Vladimir >> > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _______________________________________________ > pyxb-users mailing list > pyx...@li... > https://lists.sourceforge.net/lists/listinfo/pyxb-users > > |
From: Vladimir T. <ins...@gm...> - 2013-02-27 16:55:47
|
Actually the global Namespace should not be overriden by the local declaration because it is local to the class - the code below the local declaration should use the global Namespace instead of the local Namespace One thing that comes to my mind is to have this in the bindings: ... globalNamespace = Namespace Namespace = property(__Namespace.value, __Namespace.set, None, u'none\nThe namespace of the API definition.\n false') and everything below that uses pyxb.namespace.ExpandedName(Namespace, ..) should be pyxb.namespace.ExpandedName(globalNamespace, ..) but I will have to change everything by hand and if I regenerate the schemas I will need to do it again. On Wed, Feb 27, 2013 at 6:26 PM, Vladimir Todorov <ins...@gm...>wrote: > Hi all, > > Today I hit a problem while I was trying to import the generated bindings > for a particular schema. After some debugging I found out that the problem > is actually with the schema - it defines a property called "Namespace" (yep > ..) and in the generated code there is something like this: > > Namespace = property(__Namespace.value, __Namespace.set, None, u'none\nThe > namespace of the API definition.\n false') > > Now this is a problem because Namespace is expected to be of type > 'Namespace' but now it is of type 'property': > > File "/usr/local/lib/python2.6/dist-packages/pyxb/namespace/__init__.py", > line 183, in __init__ > raise pyxb.LogicError('ExpandedName must include a valid (perhaps > absent) namespace, or None.') > > > On line 183 in this file we have: > > if (ns is not None) and not isinstance(ns, Namespace): > raise pyxb.LogicError('ExpandedName must include a valid > (perhaps absent) namespace, or None.') > > 'ns' will be of type 'property' because of the code above. > > > The 'Namespace' property overrides the 'Namespace' variable defined in the > beginning of the generated bindings: > Namespace = pyxb.namespace.NamespaceForURI(...) > > pyxbgen --version > pyxbgen from PyXB 1.1.4 > > Unfortunately I cannot modify the schemas because I am not the owner. > Does anyone know how I can fix this (easy way)? It is extremely important > for me. > > Regards, > Vladimir > |
From: Vladimir T. <ins...@gm...> - 2013-02-27 16:27:25
|
Hi all, Today I hit a problem while I was trying to import the generated bindings for a particular schema. After some debugging I found out that the problem is actually with the schema - it defines a property called "Namespace" (yep ..) and in the generated code there is something like this: Namespace = property(__Namespace.value, __Namespace.set, None, u'none\nThe namespace of the API definition.\n false') Now this is a problem because Namespace is expected to be of type 'Namespace' but now it is of type 'property': File "/usr/local/lib/python2.6/dist-packages/pyxb/namespace/__init__.py", line 183, in __init__ raise pyxb.LogicError('ExpandedName must include a valid (perhaps absent) namespace, or None.') On line 183 in this file we have: if (ns is not None) and not isinstance(ns, Namespace): raise pyxb.LogicError('ExpandedName must include a valid (perhaps absent) namespace, or None.') 'ns' will be of type 'property' because of the code above. The 'Namespace' property overrides the 'Namespace' variable defined in the beginning of the generated bindings: Namespace = pyxb.namespace.NamespaceForURI(...) pyxbgen --version pyxbgen from PyXB 1.1.4 Unfortunately I cannot modify the schemas because I am not the owner. Does anyone know how I can fix this (easy way)? It is extremely important for me. Regards, Vladimir |
From: Peter B. <bi...@ac...> - 2013-02-01 02:20:31
|
Your original email is too long for the mailing list due to the attachment; I see this is recorded as https://sourceforge.net/apps/trac/pyxb/ticket/186. Follow-ups there for now. I can't duplicate the problem with either 1.1.6-DEV (== 1.1.5) or 1.2.2-DEV (mostly ==1.2.1), using Python 2.7.3. Please add host OS, Python version, and other relevant information to the ticket. Peter On Thu, Jan 31, 2013 at 7:38 PM, Karl Putland <ka...@si...> wrote: > The expression seems to be a valid python expression > > >>> import re > >>> r = re.compile(r"[\w*#+]*") > >>> r.findall('foo bar baz') > ['foo', '', 'bar', '', 'baz', ''] > >>> > > > > --Karl > > Karl Putland > Senior VoIP Engineer > > *SimpleSignal* > 3600 S Yosemite, Suite 150 > Denver, CO 80237 > One Number Rings All My Phones: 303-242-8608 > > SimpleSignal.com <http://www.simplesignal.com/> | Blog<http://www.simplesignal.com/blog> > | Facebook <http://www.facebook.com/SimpleSignal?ref=ts> | Twitter<http://twitter.com/simplesignal> > > > On Thu, Jan 31, 2013 at 6:31 PM, Karl Putland <ka...@si...>wrote: > >> The expression in the xsd appears valid, however it fails. Schema >> attached. >> >> >> fails on XBIngress(match='all', action1='none', digits1='', >> action2='none', digits2='') >> >> >> Traceback (most recent call last): >> File "./siptrunk.py", line 559, in <module> >> SansayXMLBuilder().main() >> File "./siptrunk.py", line 553, in main >> self.build_resource() >> File "./siptrunk.py", line 398, in build_resource >> resource = self.build_ip_resource(trunk_record) >> File "./siptrunk.py", line 352, in build_ip_resource >> rtid=trunk_record['route_table_id_number'] >> File "./siptrunk.py", line 268, in resource_factory >> 'ingress1' : self.schema.resources.XBIngress(match='all', >> action1='none', digits1='', action2='none', digits2=''), >> File "/Library/Python/2.7/site-packages/pyxb/binding/basis.py", line >> 1705, in __init__ >> fu.set(self, iv) >> File "/Library/Python/2.7/site-packages/pyxb/binding/content.py", line >> 561, in set >> value = self.__elementBinding.compatibleValue(value, >> is_plural=self.isPlural()) >> File "/Library/Python/2.7/site-packages/pyxb/binding/basis.py", line >> 1406, in compatibleValue >> return self.typeDefinition()._CompatibleValue(value, **kw) >> File "/Library/Python/2.7/site-packages/pyxb/binding/basis.py", line >> 285, in _CompatibleValue >> return cls(value) >> File "/Library/Python/2.7/site-packages/pyxb/binding/basis.py", line >> 786, in __init__ >> self.xsdConstraintsOK() >> File "/Library/Python/2.7/site-packages/pyxb/binding/basis.py", line >> 918, in xsdConstraintsOK >> return self.XsdConstraintsOK(self) >> File "/Library/Python/2.7/site-packages/pyxb/binding/basis.py", line >> 912, in XsdConstraintsOK >> if not f.validateConstraint(value): >> File "/Library/Python/2.7/site-packages/pyxb/binding/facets.py", line >> 186, in validateConstraint >> return self._validateConstraint_vx(value) >> File "/Library/Python/2.7/site-packages/pyxb/binding/facets.py", line >> 436, in _validateConstraint_vx >> if pe.matches(value): >> File "/Library/Python/2.7/site-packages/pyxb/binding/facets.py", line >> 393, in matches >> self.__compiledExpression = re.compile(self.__pythonExpression) >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/re.py", >> line 190, in compile >> return _compile(pattern, flags) >> File >> "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/re.py", >> line 245, in _compile >> raise error, v # invalid expression >> sre_constants.error: bad character range >> >> >> >> --Karl >> >> Karl Putland >> Senior VoIP Engineer >> >> *SimpleSignal* >> 3600 S Yosemite, Suite 150 >> Denver, CO 80237 >> One Number Rings All My Phones: 303-242-8608 >> >> SimpleSignal.com <http://www.simplesignal.com/> | Blog<http://www.simplesignal.com/blog> >> | Facebook <http://www.facebook.com/SimpleSignal?ref=ts> | Twitter<http://twitter.com/simplesignal> >> > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_jan > _______________________________________________ > pyxb-users mailing list > pyx...@li... > https://lists.sourceforge.net/lists/listinfo/pyxb-users > > |
From: Karl P. <ka...@si...> - 2013-02-01 01:45:37
|
The expression seems to be a valid python expression >>> import re >>> r = re.compile(r"[\w*#+]*") >>> r.findall('foo bar baz') ['foo', '', 'bar', '', 'baz', ''] >>> --Karl Karl Putland Senior VoIP Engineer *SimpleSignal* 3600 S Yosemite, Suite 150 Denver, CO 80237 One Number Rings All My Phones: 303-242-8608 SimpleSignal.com <http://www.simplesignal.com/> | Blog<http://www.simplesignal.com/blog> | Facebook <http://www.facebook.com/SimpleSignal?ref=ts> | Twitter<http://twitter.com/simplesignal> On Thu, Jan 31, 2013 at 6:31 PM, Karl Putland <ka...@si...> wrote: > The expression in the xsd appears valid, however it fails. Schema attached. > > > fails on XBIngress(match='all', action1='none', digits1='', > action2='none', digits2='') > > > Traceback (most recent call last): > File "./siptrunk.py", line 559, in <module> > SansayXMLBuilder().main() > File "./siptrunk.py", line 553, in main > self.build_resource() > File "./siptrunk.py", line 398, in build_resource > resource = self.build_ip_resource(trunk_record) > File "./siptrunk.py", line 352, in build_ip_resource > rtid=trunk_record['route_table_id_number'] > File "./siptrunk.py", line 268, in resource_factory > 'ingress1' : self.schema.resources.XBIngress(match='all', > action1='none', digits1='', action2='none', digits2=''), > File "/Library/Python/2.7/site-packages/pyxb/binding/basis.py", line > 1705, in __init__ > fu.set(self, iv) > File "/Library/Python/2.7/site-packages/pyxb/binding/content.py", line > 561, in set > value = self.__elementBinding.compatibleValue(value, > is_plural=self.isPlural()) > File "/Library/Python/2.7/site-packages/pyxb/binding/basis.py", line > 1406, in compatibleValue > return self.typeDefinition()._CompatibleValue(value, **kw) > File "/Library/Python/2.7/site-packages/pyxb/binding/basis.py", line > 285, in _CompatibleValue > return cls(value) > File "/Library/Python/2.7/site-packages/pyxb/binding/basis.py", line > 786, in __init__ > self.xsdConstraintsOK() > File "/Library/Python/2.7/site-packages/pyxb/binding/basis.py", line > 918, in xsdConstraintsOK > return self.XsdConstraintsOK(self) > File "/Library/Python/2.7/site-packages/pyxb/binding/basis.py", line > 912, in XsdConstraintsOK > if not f.validateConstraint(value): > File "/Library/Python/2.7/site-packages/pyxb/binding/facets.py", line > 186, in validateConstraint > return self._validateConstraint_vx(value) > File "/Library/Python/2.7/site-packages/pyxb/binding/facets.py", line > 436, in _validateConstraint_vx > if pe.matches(value): > File "/Library/Python/2.7/site-packages/pyxb/binding/facets.py", line > 393, in matches > self.__compiledExpression = re.compile(self.__pythonExpression) > File > "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/re.py", > line 190, in compile > return _compile(pattern, flags) > File > "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/re.py", > line 245, in _compile > raise error, v # invalid expression > sre_constants.error: bad character range > > > > --Karl > > Karl Putland > Senior VoIP Engineer > > *SimpleSignal* > 3600 S Yosemite, Suite 150 > Denver, CO 80237 > One Number Rings All My Phones: 303-242-8608 > > SimpleSignal.com <http://www.simplesignal.com/> | Blog<http://www.simplesignal.com/blog> > | Facebook <http://www.facebook.com/SimpleSignal?ref=ts> | Twitter<http://twitter.com/simplesignal> > |
From: Peter B. <bi...@ac...> - 2013-01-05 12:46:05
|
In the definition of the type that contains the element, the hidden element class attribute is assigned an ElementDeclaration instance. The third argument to the constructor is True iff the element is plural: # Element Value uses Python identifier Value __Value = pyxb.binding.content.ElementDeclaration(pyxb.namespace.ExpandedName(None, u'Value'), 'Value', '__AbsentNamespace0_CTD_ANON_Value', True, pyxb.utils.utility.Location(None, 6, 8), ) Generally it's better to look at the schema to determine how the elements operate. With the new FAC-based content model figuring out occurrence restrictions from the generated code is much harder. Peter On Fri, Jan 4, 2013 at 10:23 PM, Aaron Storm <aar...@ya...> wrote: > Peter - Thank you so much! > > You were right regarding multiple Value elements. Your example works. > > >> example.Field[0].Name #works > status > > >> example.Field[0].Value[0].value #works > Open > > >> example.Field[0].Value[0].ReferenceValue #works > Some Ref Value > > I was comparing against examples/content/showcontent.py and didn't realize > my schema specify multiple occurrences. > Is there anything on the generated module that gives hints for something > like this? > > Again, thank a lot! > > Regards, > A > > ------------------------------ > *From:* Peter Bigot <bi...@ac...> > *To:* Aaron Storm <aar...@ya...> > *Cc:* "pyx...@li..." <pyx...@li...> > > *Sent:* Friday, January 4, 2013 7:24 PM > *Subject:* Re: [pyxb-users] Issue with Complex type with content type > SIMPLE > > I assume "example" below is an instance of a complex type you didn't > provide. I think the issue is that there is only one Field in whatever > that containing element is, while there are multiple Value elements in a > single Field element. > > xmls = '<Field Name="status"><Value ReferenceValue="Some Ref > Value">Open</Value></Field>' > instance = CreateFromDocument(xmls) > print instance.toxml('utf-8') > print instance.Name > print 'Field %s has %u values' % (instance.Name, > len(instance.Value)) > for v in instance.Value: > print 'Value type %s is %s' % (v.ReferenceValue, v.value()) > > produces: > > <?xml version="1.0" encoding="utf-8"?><Field Name="status"><Value > ReferenceValue="Some Ref Value">Open</Value></Field> > status > Field status has 1 values > Value type Some Ref Value is Open > > Peter > > On Fri, Jan 4, 2013 at 1:12 PM, Aaron Storm <aar...@ya...> wrote: > > Issue with Complex type with content type SIMPLE > > > I am having problems trying to access the content of an element. Any idea > what I should do? > > > >> example.Field[0].Name #works > status > > >> example.Field[0].Value #doesn't work > >> example.Field[0].Value.value #doesn't work > >> example.Field[0].Value.ReferenceValue #doesn't work > > > Here is the snippet of the xml and xsd: > > xml: > <Field Name="status"> > <Value ReferenceValue="Some Ref Value">Open</Value> > </Field> > > xsd>: > <xs:element name="Field" maxOccurs="unbounded"> > <xs:annotation> > <xs:documentation>A single field.</xs:documentation> > </xs:annotation> > <xs:complexType> > <xs:sequence> > <xs:element name="Value" minOccurs="0" maxOccurs="unbounded"> > <xs:annotation> > <xs:documentation>The current value of the field in this > entity instance. Multi-value fields contain multi-value elements. Reference > fields contain the ReferenceValue attribute.</xs:documentation> > </xs:annotation> > <xs:complexType> > <xs:simpleContent> > <xs:extension base="xs:string"> > <xs:attribute name="ReferenceValue" type="xs:string" > use="optional"/> > </xs:extension> > </xs:simpleContent> > </xs:complexType> > </xs:element> > </xs:sequence> > <xs:attribute name="Name" type="xs:string" use="required"> > <xs:annotation> > <xs:documentation>The field name.</xs:documentation> > </xs:annotation> > </xs:attribute> > </xs:complexType> > </xs:element> > > Generated class: > > # Complex type [anonymous] with content type SIMPLE > class CTD_ANON_3 (pyxb.binding.basis.complexTypeDefinition): > """The current value of the field in this entity instance. Multi-value > fields contain multi-value elements. Reference fields contain the > ReferenceValue attribute.""" > _TypeDefinition = pyxb.binding.datatypes.string > _ContentTypeTag = pyxb.binding.basis.complexTypeDefinition._CT_SIMPLE > _Abstract = False > _ExpandedName = None > _XSDLocation = > pyxb.utils.utility.Location('C:\\Temp\\rest\\xsd\\Entity.xsd', 25, 11) > # Base type is pyxb.binding.datatypes.string > > # Attribute ReferenceValue uses Python identifier ReferenceValue > __ReferenceValue = > pyxb.binding.content.AttributeUse(pyxb.namespace.ExpandedName(None, > u'ReferenceValue'), 'ReferenceValue', > '__AbsentNamespace0_CTD_ANON_3_ReferenceValue', > pyxb.binding.datatypes.string) > __ReferenceValue._DeclarationLocation = > pyxb.utils.utility.Location('C:\\Temp\\rest\\xsd\\Entity.xsd', 28, 14) > __ReferenceValue._UseLocation = > pyxb.utils.utility.Location('C:\\Temp\\rest\\xsd\\Entity.xsd', 28, 14) > > ReferenceValue = property(__ReferenceValue.value, > __ReferenceValue.set, None, None) > > > _ElementMap = { > > } > _AttributeMap = { > __ReferenceValue.name() : __ReferenceValue > } > > > Regards, > > > ------------------------------------------------------------------------------ > Master HTML5, CSS3, ASP.NET <http://asp.net/>, MVC, AJAX, Knockout.js, > Web API and > much more. Get web development skills now with LearnDevNow - > 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. > SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122812 > _______________________________________________ > pyxb-users mailing list > pyx...@li... > https://lists.sourceforge.net/lists/listinfo/pyxb-users > > > > > |
From: Aaron S. <aar...@ya...> - 2013-01-05 04:23:16
|
Peter - Thank you so much! You were right regarding multiple Value elements. Your example works. >> example.Field[0].Name #works status >> example.Field[0].Value[0].value #works Open >> example.Field[0].Value[0].ReferenceValue #works Some Ref Value I was comparing against examples/content/showcontent.py and didn't realize my schema specify multiple occurrences. Is there anything on the generated module that gives hints for something like this? Again, thank a lot! Regards, A ________________________________ From: Peter Bigot <bi...@ac...> To: Aaron Storm <aar...@ya...> Cc: "pyx...@li..." <pyx...@li...> Sent: Friday, January 4, 2013 7:24 PM Subject: Re: [pyxb-users] Issue with Complex type with content type SIMPLE I assume "example" below is an instance of a complex type you didn't provide. I think the issue is that there is only one Field in whatever that containing element is, while there are multiple Value elements in a single Field element. xmls = '<Field Name="status"><Value ReferenceValue="Some Ref Value">Open</Value></Field>' instance = CreateFromDocument(xmls) print instance.toxml('utf-8') print instance.Name print 'Field %s has %u values' % (instance.Name, len(instance.Value)) for v in instance.Value: print 'Value type %s is %s' % (v.ReferenceValue, v.value()) produces: <?xml version="1.0" encoding="utf-8"?><Field Name="status"><Value ReferenceValue="Some Ref Value">Open</Value></Field> status Field status has 1 values Value type Some Ref Value is Open Peter On Fri, Jan 4, 2013 at 1:12 PM, Aaron Storm <aar...@ya...> wrote: Issue with Complex type with content type SIMPLE > > >I am having problems trying to access the content of an element. Any idea what I should do? > > >>> example.Field[0].Name #works >status > >>> example.Field[0].Value #doesn't work >>> example.Field[0].Value.value #doesn't work >>> example.Field[0].Value.ReferenceValue #doesn't work > > >Here is the snippet of the xml and xsd: > >xml: > <Field Name="status"> > <Value ReferenceValue="Some Ref Value">Open</Value> > </Field> > >xsd>: > <xs:element name="Field" maxOccurs="unbounded"> > <xs:annotation> > <xs:documentation>A single field.</xs:documentation> > </xs:annotation> > <xs:complexType> > <xs:sequence> > <xs:element name="Value" minOccurs="0" maxOccurs="unbounded"> > <xs:annotation> > <xs:documentation>The current value of the field in this entity instance. Multi-value fields contain multi-value elements. Reference fields contain the ReferenceValue attribute.</xs:documentation> > </xs:annotation> > <xs:complexType> > <xs:simpleContent> > <xs:extension base="xs:string"> > <xs:attribute name="ReferenceValue" type="xs:string" use="optional"/> > </xs:extension> > </xs:simpleContent> > </xs:complexType> > </xs:element> > </xs:sequence> > <xs:attribute name="Name" type="xs:string" use="required"> > <xs:annotation> > <xs:documentation>The field name.</xs:documentation> > </xs:annotation> > </xs:attribute> > </xs:complexType> > </xs:element> > >Generated class: > ># Complex type [anonymous] with content type SIMPLE >class CTD_ANON_3 (pyxb.binding.basis.complexTypeDefinition): > """The current value of the field in this entity instance. Multi-value fields contain multi-value elements. Reference fields contain the ReferenceValue attribute.""" > _TypeDefinition = pyxb.binding.datatypes.string > _ContentTypeTag = pyxb.binding.basis.complexTypeDefinition._CT_SIMPLE > _Abstract = False > _ExpandedName = None > _XSDLocation = pyxb.utils.utility.Location('C:\\Temp\\rest\\xsd\\Entity.xsd', 25, 11) > # Base type is pyxb.binding.datatypes.string > > # Attribute ReferenceValue uses Python identifier ReferenceValue > __ReferenceValue = pyxb.binding.content.AttributeUse(pyxb.namespace.ExpandedName(None, u'ReferenceValue'), 'ReferenceValue', '__AbsentNamespace0_CTD_ANON_3_ReferenceValue', pyxb.binding.datatypes.string) > __ReferenceValue._DeclarationLocation = pyxb.utils.utility.Location('C:\\Temp\\rest\\xsd\\Entity.xsd', 28, 14) > __ReferenceValue._UseLocation = pyxb.utils.utility.Location('C:\\Temp\\rest\\xsd\\Entity.xsd', 28, 14) > > ReferenceValue = property(__ReferenceValue.value, __ReferenceValue.set, None, None) > > > _ElementMap = { > > } > _AttributeMap = { > __ReferenceValue.name() : __ReferenceValue > } > > > > >Regards, >------------------------------------------------------------------------------ >Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and >much more. Get web development skills now with LearnDevNow - >350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. >SALE $99.99 this month only -- learn more at: >http://p.sf.net/sfu/learnmore_122812 >_______________________________________________ >pyxb-users mailing list >pyx...@li... >https://lists.sourceforge.net/lists/listinfo/pyxb-users > > |
From: Peter B. <bi...@ac...> - 2013-01-05 00:24:31
|
I assume "example" below is an instance of a complex type you didn't provide. I think the issue is that there is only one Field in whatever that containing element is, while there are multiple Value elements in a single Field element. xmls = '<Field Name="status"><Value ReferenceValue="Some Ref Value">Open</Value></Field>' instance = CreateFromDocument(xmls) print instance.toxml('utf-8') print instance.Name print 'Field %s has %u values' % (instance.Name, len(instance.Value)) for v in instance.Value: print 'Value type %s is %s' % (v.ReferenceValue, v.value()) produces: <?xml version="1.0" encoding="utf-8"?><Field Name="status"><Value ReferenceValue="Some Ref Value">Open</Value></Field> status Field status has 1 values Value type Some Ref Value is Open Peter On Fri, Jan 4, 2013 at 1:12 PM, Aaron Storm <aar...@ya...> wrote: > Issue with Complex type with content type SIMPLE > > > I am having problems trying to access the content of an element. Any idea > what I should do? > > > >> example.Field[0].Name #works > status > > >> example.Field[0].Value #doesn't work > >> example.Field[0].Value.value #doesn't work > >> example.Field[0].Value.ReferenceValue #doesn't work > > > Here is the snippet of the xml and xsd: > > xml: > <Field Name="status"> > <Value ReferenceValue="Some Ref Value">Open</Value> > </Field> > > xsd>: > <xs:element name="Field" maxOccurs="unbounded"> > <xs:annotation> > <xs:documentation>A single field.</xs:documentation> > </xs:annotation> > <xs:complexType> > <xs:sequence> > <xs:element name="Value" minOccurs="0" maxOccurs="unbounded"> > <xs:annotation> > <xs:documentation>The current value of the field in this > entity instance. Multi-value fields contain multi-value elements. Reference > fields contain the ReferenceValue attribute.</xs:documentation> > </xs:annotation> > <xs:complexType> > <xs:simpleContent> > <xs:extension base="xs:string"> > <xs:attribute name="ReferenceValue" type="xs:string" > use="optional"/> > </xs:extension> > </xs:simpleContent> > </xs:complexType> > </xs:element> > </xs:sequence> > <xs:attribute name="Name" type="xs:string" use="required"> > <xs:annotation> > <xs:documentation>The field name.</xs:documentation> > </xs:annotation> > </xs:attribute> > </xs:complexType> > </xs:element> > > Generated class: > > # Complex type [anonymous] with content type SIMPLE > class CTD_ANON_3 (pyxb.binding.basis.complexTypeDefinition): > """The current value of the field in this entity instance. Multi-value > fields contain multi-value elements. Reference fields contain the > ReferenceValue attribute.""" > _TypeDefinition = pyxb.binding.datatypes.string > _ContentTypeTag = pyxb.binding.basis.complexTypeDefinition._CT_SIMPLE > _Abstract = False > _ExpandedName = None > _XSDLocation = > pyxb.utils.utility.Location('C:\\Temp\\rest\\xsd\\Entity.xsd', 25, 11) > # Base type is pyxb.binding.datatypes.string > > # Attribute ReferenceValue uses Python identifier ReferenceValue > __ReferenceValue = > pyxb.binding.content.AttributeUse(pyxb.namespace.ExpandedName(None, > u'ReferenceValue'), 'ReferenceValue', > '__AbsentNamespace0_CTD_ANON_3_ReferenceValue', > pyxb.binding.datatypes.string) > __ReferenceValue._DeclarationLocation = > pyxb.utils.utility.Location('C:\\Temp\\rest\\xsd\\Entity.xsd', 28, 14) > __ReferenceValue._UseLocation = > pyxb.utils.utility.Location('C:\\Temp\\rest\\xsd\\Entity.xsd', 28, 14) > > ReferenceValue = property(__ReferenceValue.value, > __ReferenceValue.set, None, None) > > > _ElementMap = { > > } > _AttributeMap = { > __ReferenceValue.name() : __ReferenceValue > } > > > Regards, > > > ------------------------------------------------------------------------------ > Master HTML5, CSS3, ASP.NET, MVC, AJAX, Knockout.js, Web API and > much more. Get web development skills now with LearnDevNow - > 350+ hours of step-by-step video tutorials by Microsoft MVPs and experts. > SALE $99.99 this month only -- learn more at: > http://p.sf.net/sfu/learnmore_122812 > _______________________________________________ > pyxb-users mailing list > pyx...@li... > https://lists.sourceforge.net/lists/listinfo/pyxb-users > > |
From: Aaron S. <aar...@ya...> - 2013-01-04 19:12:17
|
Issue with Complex type with content type SIMPLE I am having problems trying to access the content of an element. Any idea what I should do? >> example.Field[0].Name #works status >> example.Field[0].Value #doesn't work >> example.Field[0].Value.value #doesn't work >> example.Field[0].Value.ReferenceValue #doesn't work Here is the snippet of the xml and xsd: xml: <Field Name="status"> <Value ReferenceValue="Some Ref Value">Open</Value> </Field> xsd>: <xs:element name="Field" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>A single field.</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="Value" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>The current value of the field in this entity instance. Multi-value fields contain multi-value elements. Reference fields contain the ReferenceValue attribute.</xs:documentation> </xs:annotation> <xs:complexType> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="ReferenceValue" type="xs:string" use="optional"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name="Name" type="xs:string" use="required"> <xs:annotation> <xs:documentation>The field name.</xs:documentation> </xs:annotation> </xs:attribute> </xs:complexType> </xs:element> Generated class: # Complex type [anonymous] with content type SIMPLE class CTD_ANON_3 (pyxb.binding.basis.complexTypeDefinition): """The current value of the field in this entity instance. Multi-value fields contain multi-value elements. Reference fields contain the ReferenceValue attribute.""" _TypeDefinition = pyxb.binding.datatypes.string _ContentTypeTag = pyxb.binding.basis.complexTypeDefinition._CT_SIMPLE _Abstract = False _ExpandedName = None _XSDLocation = pyxb.utils.utility.Location('C:\\Temp\\rest\\xsd\\Entity.xsd', 25, 11) # Base type is pyxb.binding.datatypes.string # Attribute ReferenceValue uses Python identifier ReferenceValue __ReferenceValue = pyxb.binding.content.AttributeUse(pyxb.namespace.ExpandedName(None, u'ReferenceValue'), 'ReferenceValue', '__AbsentNamespace0_CTD_ANON_3_ReferenceValue', pyxb.binding.datatypes.string) __ReferenceValue._DeclarationLocation = pyxb.utils.utility.Location('C:\\Temp\\rest\\xsd\\Entity.xsd', 28, 14) __ReferenceValue._UseLocation = pyxb.utils.utility.Location('C:\\Temp\\rest\\xsd\\Entity.xsd', 28, 14) ReferenceValue = property(__ReferenceValue.value, __ReferenceValue.set, None, None) _ElementMap = { } _AttributeMap = { __ReferenceValue.name() : __ReferenceValue } Regards, |
From: Peter B. <bi...@ac...> - 2012-12-17 19:40:57
|
No significant problems reported relative to the new content model, so it's no longer beta. Release notes below. The big change is proper handling of mixed content; you can now use PyXB for xhtml. (I swear, the capability is there, even if the documentation of how to use it is weak. Ask questions and I'll be motivated to improve it.) Peter 1.2.1 (17 Dec 2012) ------------------- .. warning:: This release has an interface change: the :api:`content <pyxb.binding.basis.complexTypeDefinition.content>` method on complex types is now deprecated in favor of the :api:`orderedContent <pyxb.binding.basis.complexTypeDefinition.orderedContent>` method. The members in the new list have wrapper classes to correctly associate instance bindings with the element declaration and to distinguish instances with string values from non-element character data. The old method is supported for this release, but will produce a warning when used, and is likely to be removed in the next release. Key features of the release: - Full support for mixed content schema through a new method :api:`orderedContent <pyxb.binding.basis.complexTypeDefinition.orderedContent>` on complex binding instances and flags that control when that list affects document generation. See :ref:`mixed_content`. This is particularly relevant to XHTML. - Immediate validation of values assigned to plural elements. - A first step to providing finer control of validation, using :api:`pyxb.ValidationConfig` The following reported `defects/enhancements <http://sourceforge.net/apps/trac/pyxb/>`_ have been addressed: - Validate :ref:`pyxb.BIND<pyxb_BIND>` at point of use. :ticket:`69` - Issues with renamed element (most of which were mis-use of pyxb.BIND). :ticket:`71` - Support for default and fixed values in elements. :ticket:`99` - Support for mixed content. :ticket:`153`, :ticket:`154` - Provide an example based on a `help-forum thread <http://sourceforge.net/projects/pyxb/forums/forum/956708/topic/5422611/ >`_ to show how to take advantage of PyXB 1.2.x improved diagnostics. :ticket:`158` - Improve interpretation of Python native type values when used in element constructors. :ticket:`175` - Add :ref:`ECMA-376 (Office Open XML)<bundle_ecma376>` as an optional bundle. :ticket:`178` - Fix invalid error when an all model group had minOccurs=0. :ticket:`179` - Add :ref:`Dublin Core<bundle_dc>` to the standard bundles. :ticket:`180` - Allow control of element order in generated documents. :ticket:`181` - Include wildcard elements in content. :ticket:`182` |
From: Peter B. <bi...@ac...> - 2012-11-08 02:01:25
|
PyXB 1.2.0 has just been released to SourceForge at: https://sourceforge.net/projects/pyxb/files/pyxb/1.2.0/ The release notes are at: http://pyxb.sourceforge.net/releases.html#nov-2012 An example of how diagnostics are improved with this version is at: http://pyxb.sourceforge.net/userref_validating.html#validating The ultra-cool new content model is described at: http://pyxb.sourceforge.net/arch_content.html#validating-content Please grab a copy of this version and try it out. It's only available from SourceForge from the link given above. I'm not making it the default version until somebody other than me checks it out and I find time to address a few more of the open issues. PyPI packaging will also occur when it's stable. NOTE: - You need Python 2.6 or Python 2.7 for this. Some of the tests won't work under Python 2.6, but due to flaws in the test infrastructure not PyXB. - The exception hierarchy changed a lot. You also will have to regenerate all bindings (they're never compatible between PyXB releases). Otherwise there should be little need to change your code. - I'll provide as much support as I can but I'm going to be switching back to focus on paid contract work for the next month, so don't expect another release until near the end of the year. If you try out 1.2.0 and run into problems, that might make the release (and the corresponding fixes) occur sooner. (Just sayin'.) Peter |
From: Peter B. <bi...@ac...> - 2012-11-01 21:25:06
|
I ran into complications with the new automata model back in September and couldn't get it straightened out in the time I could then spare. I got back to it this week, fixed the problems, and PyXB-1.2.x development is now rolling again. If you track the repository, the next and master branches are now gone because of the version fork. pyxb-1.1/next and pyxb-1.1/master track the old stuff. pyxb-1.2/next is where 1.2.x development is going on. As I mentioned back in August, PyXB-1.2.x is intended to lead to Python3 support. Consequently, Python 2.4 and 2.5 are no longer supported, and you may need Python 2.6 as a minimum. As of now, pyxb-1.2/next has the new content model, and as best I can tell all the issues with the old greedy mechanism getting confused have been eliminated. The implementation is based on "Regular Expressions with Numerical Constraints and Automata with Counters", Dag Hovland, Lecture Notes in Computer Science, 2009, Volume 5684, Theoretical Aspects of Computing - ICTAC 2009, Pages 231-245. If you're interested, you can get a copy at: https://bora.uib.no/bitstream/1956/3628/3/Hovland_LNCS%205684.pdf As of this morning all tests pass, but there's much to be done, including architecture documentation updates, replacing the exception hierarchy, etc. However, I expect this to be very nice because if validation fails it should tell you exactly what it's expecting, and maybe even where in the original schema it was when it lost track of itself. It's out there if you want to play with it, but it's not really ready for anything more than hard-core hackers to use. I hope to get a preliminary release ready in the next 10 days, but historically PyXB development has taken longer than I've wished, so don't get too excited. Peter On Thu, Aug 30, 2012 at 6:36 AM, Peter Bigot <bi...@ac...> wrote: > A few notes on upcoming PyXB plans: > > * A candidate for the 1.1.5 release is in the next branch of the git > repository at > http://pyxb.git.sourceforge.net/git/gitweb.cgi?p=pyxb/pyxb;a=summary. All > bugs and contributed patches that are appropriate for this version have > been integrated. Please see the project status page at > https://sourceforge.net/apps/trac/pyxb/ for details. The release will be > made at some appropriate time in the future, probably within three weeks; > any bugs reported before then will be considered for integration in the > release. > > * 1.1.5 is expected to be the last release in the 1.1.x series. Only > the discovery of a critical error would result in a further release or > maintenance of that series. > > * 1.2.0 is in active development and will fork from 1.1.x somewhere near the > current head of next. The highlight of 1.2.x is a new content model based > on Finite Automata with Counters that I expect to provide a huge > improvement in diagnostics and to correct issues with the current greedy > parsing approach. PyXB 1.2.x should debut before the end of September. > > * The 1.1.x series is the last series that will support Python 2.4 and > Python 2.5. The minimum version for 1.2.x will be Python 2.6. > > * Once 1.2.x becomes stable, a 1.3.x version of PyXB that will support > Python3 will be created. I anticipate supporting 1.2.x and 1.3.x in > parallel, unless it turns out that 1.3.x can be made to work under > Python2. Some of the changes in 1.2.x will be to remove constructs that > will not be available under Python3 (hence the loss of support for Python > 2.4 and Python 2.5). > > Any comments/questions/concerns? > > Peter |
From: Peter B. <bi...@ac...> - 2012-11-01 21:11:35
|
Release notes below. As usual, questions here and bug reports on the trac page. http://sourceforge.net/apps/trac/pyxb/ 1.1.5 (01 Nov 2012) ------------------- This is a maintenance release to finalize the 1.1.x series before starting the 1.2.x series. The following reported `defects/enhancements <http://sourceforge.net/apps/trac/pyxb/>`_ have been addressed: - The standard Python logging module is now used. :ticket:`17`, :ticket:`159`, :ticket:`157` - The potential for changing binding style support has been removed. :ticket:`82` - PyPI/setuptools support has been fixed (again). :ticket:`130` - Unit test setup/teardown has been reviewed. :ticket:`149` - utf-8 is now used in all PyXB source files. :ticket:`151` - Preserve namespace mappings in deep-cloned instances. :ticket:`155` - Fix problems revealed by cython and pyflakes. :ticket:`156`, :ticket:`167` - User contributions from Jon Foster, with the exception of windows test scripts, have been incorporated. :ticket:`157` - Correct issues in generator function to retrieve command line. :ticket:`161` - Restore content of ExtraContentError exception. :ticket:`163` - Warn rather than abort when apparently redundant schema are included. :ticket:`169` |
From: Peter B. <bi...@ac...> - 2012-08-30 11:37:04
|
A few notes on upcoming PyXB plans: * A candidate for the 1.1.5 release is in the next branch of the git repository at http://pyxb.git.sourceforge.net/git/gitweb.cgi?p=pyxb/pyxb;a=summary. All bugs and contributed patches that are appropriate for this version have been integrated. Please see the project status page at https://sourceforge.net/apps/trac/pyxb/ for details. The release will be made at some appropriate time in the future, probably within three weeks; any bugs reported before then will be considered for integration in the release. * 1.1.5 is expected to be the last release in the 1.1.x series. Only the discovery of a critical error would result in a further release or maintenance of that series. * 1.2.0 is in active development and will fork from 1.1.x somewhere near the current head of next. The highlight of 1.2.x is a new content model based on Finite Automata with Counters that I expect to provide a huge improvement in diagnostics and to correct issues with the current greedy parsing approach. PyXB 1.2.x should debut before the end of September. * The 1.1.x series is the last series that will support Python 2.4 and Python 2.5. The minimum version for 1.2.x will be Python 2.6. * Once 1.2.x becomes stable, a 1.3.x version of PyXB that will support Python3 will be created. I anticipate supporting 1.2.x and 1.3.x in parallel, unless it turns out that 1.3.x can be made to work under Python2. Some of the changes in 1.2.x will be to remove constructs that will not be available under Python3 (hence the loss of support for Python 2.4 and Python 2.5). Any comments/questions/concerns? Peter |
From: Peter B. <pa...@us...> - 2012-08-26 00:21:01
|
I've done the first pass through your proposed changes to PyXB. Thank you for making them so clean. I took almost all of the unicode-related stuff. I didn't incorporate the code that downloaded the tables automatically: having made mistakes with that in the past (including when trac/134's change updated the unicode tables based on the wrong version) I'd rather keep it manual. I also didn't take the code that merged adjacent codepoint blocks; seems like the win would be small, and I'd like to maintain a clear mapping between the tables and the original files, though that might not be technically justifiable. I also took all the XML regular expression updates, which I think are a great improvement. In addition to putting your name in the NOTICE file as a Contributor, I added you as a copyright holder for pyxb.binding.xmlre.py since a lot of it is now your code. I made a few changes within the patch if it was tiny (mostly style issues) or as a second refinement patch. All are now in the next branch of the git repository on SourceForge. If you have concerns about the changes, let me know. Still pending are: * use of the logging module. I do want something like this, but have to see how it works controlling logging on a per-module basis (it's been a couple years since I used that module) * use of os.pathsep which I'll probably take though with edits; I haven't looked closely yet * updates to make tests pass on Windows, which I may put in a branch until you or somebody else can confirm that the things actually work Not sure when I'll get to those, but I plan to do a fair amount of work on PyXB in the next couple weeks so it should be within that time period. Peter On Wed, Jul 4, 2012 at 12:20 PM, Jon Foster <jo...@jo...> wrote: > Hi Peter, > > I've been using PyXB for a while now, and I have some fixes to > contribute. > > I've uploaded my changes to GitHub, here: > https://github.com/jonfoster/pyxb1.git > git://github.com/jonfoster/pyxb1.git > > The changes I've made are: > > - Fix many bugs in the XSD regular expression parsing. > These bugs made it impossible to use PyXB for certain > schemas. I've also added a lot of new unit tests for this > area. As part of this work, there were some fixes to the > Unicode definitions used by the regular expression code. > > - Change to use Python's standard logging rather than "print". > This is partly to prevent PyXB from messing up terminal-based > UIs by printing unwanted messages; and partly to ensure the > logs go somewhere useful when run in a web app or daemon. > > - Change the archive search path to use the platform's normal > path separator, rather than hardcoding ":". On Linux there is > no change; but on Windows the separator changes to ";" so you > can use Windows paths with drive letters (e.g. "C:\foo;D:\bar"). > This was done to help get some of the unit tests running on > Windows. Note that this is a backwards-incompatible change, > but given this feature was so limited on Windows I don't think > anyone will mind. > > - Fixes and tweaks to get the unit tests working on Windows. > > There's one more thing I'm still trying to fix, but might not be > ready for 1.1.5: > > - I'm trying to get PyXB to be consistent about it's output. > Currently it's impossible to reliably reproduce PyXB bindings, > since PyXB seems to regularly re-order it's output and renumber > anonymous types. So to get a reproducible build the generated > PyXB bindings have to be checked in to version control, and > checking in generated files isn't nice. It's also impossible > to look at diffs between different versions of the bindings, > because there can be huge differences even if they were > generated from the same XSD and have the same effect. > > Kind regards, > > Jon |
From: Peter B. <pa...@us...> - 2012-07-04 19:12:11
|
On Wed, Jul 4, 2012 at 12:20 PM, Jon Foster <jo...@jo...> wrote: > There's one more thing I'm still trying to fix, but might not be > ready for 1.1.5: > > - I'm trying to get PyXB to be consistent about it's output. > Currently it's impossible to reliably reproduce PyXB bindings, > since PyXB seems to regularly re-order it's output and renumber > anonymous types. So to get a reproducible build the generated > PyXB bindings have to be checked in to version control, and > checking in generated files isn't nice. It's also impossible > to look at diffs between different versions of the bindings, > because there can be huge differences even if they were > generated from the same XSD and have the same effect. I have to recommend holding off on this. https://sourceforge.net/apps/trac/pyxb/ticket/112 is on the queue for 1.1.5, and the changes in generation and the content model are likely to be really pervasive. I sympathize with the goal in part. Being able to check for differences in the generated bindings is helpful during development. I'm not immediately in favor of adding generated code to a repository (except at a release point, where it's archival, and historical differences should not matter). But your comment does raise the possibility of interchange issues with two installations from the same schema and PyXB version if pickled files (archives or serialized data) are involved. I haven't thought of the ramifications of that. I probably wouldn't merge in a change like this, mostly because it'd conflict with #112. Could you instead add a new ticket for this feature, perhaps addressing problems that the lack of reproducibility creates (other than version control), so that I keep it in mind when doing the next update? Thanks. Peter |
From: Peter B. <pa...@us...> - 2012-07-04 18:16:55
|
Just taking a quick look, I appreciate your contributions, especially that they seem to be small independent changes that will be easy to review. Next time I'm back on PyXB (later this month, perhaps) I'll do a more complete look, merge in what I can, and start a discussion if there's anything I'd prefer to solve a different way or after some of the more major changes slated for the next couple releases. Thanks. Peter On Wed, Jul 4, 2012 at 12:20 PM, Jon Foster <jo...@jo...> wrote: > Hi Peter, > > I've been using PyXB for a while now, and I have some fixes to > contribute. > > I've uploaded my changes to GitHub, here: > https://github.com/jonfoster/pyxb1.git > git://github.com/jonfoster/pyxb1.git > > The changes I've made are: > > - Fix many bugs in the XSD regular expression parsing. > These bugs made it impossible to use PyXB for certain > schemas. I've also added a lot of new unit tests for this > area. As part of this work, there were some fixes to the > Unicode definitions used by the regular expression code. > > - Change to use Python's standard logging rather than "print". > This is partly to prevent PyXB from messing up terminal-based > UIs by printing unwanted messages; and partly to ensure the > logs go somewhere useful when run in a web app or daemon. > > - Change the archive search path to use the platform's normal > path separator, rather than hardcoding ":". On Linux there is > no change; but on Windows the separator changes to ";" so you > can use Windows paths with drive letters (e.g. "C:\foo;D:\bar"). > This was done to help get some of the unit tests running on > Windows. Note that this is a backwards-incompatible change, > but given this feature was so limited on Windows I don't think > anyone will mind. > > - Fixes and tweaks to get the unit tests working on Windows. > > There's one more thing I'm still trying to fix, but might not be > ready for 1.1.5: > > - I'm trying to get PyXB to be consistent about it's output. > Currently it's impossible to reliably reproduce PyXB bindings, > since PyXB seems to regularly re-order it's output and renumber > anonymous types. So to get a reproducible build the generated > PyXB bindings have to be checked in to version control, and > checking in generated files isn't nice. It's also impossible > to look at diffs between different versions of the bindings, > because there can be huge differences even if they were > generated from the same XSD and have the same effect. > > Kind regards, > > Jon |
From: Jon F. <jo...@jo...> - 2012-07-04 17:33:13
|
Hi Peter, I've been using PyXB for a while now, and I have some fixes to contribute. I've uploaded my changes to GitHub, here: https://github.com/jonfoster/pyxb1.git git://github.com/jonfoster/pyxb1.git The changes I've made are: - Fix many bugs in the XSD regular expression parsing. These bugs made it impossible to use PyXB for certain schemas. I've also added a lot of new unit tests for this area. As part of this work, there were some fixes to the Unicode definitions used by the regular expression code. - Change to use Python's standard logging rather than "print". This is partly to prevent PyXB from messing up terminal-based UIs by printing unwanted messages; and partly to ensure the logs go somewhere useful when run in a web app or daemon. - Change the archive search path to use the platform's normal path separator, rather than hardcoding ":". On Linux there is no change; but on Windows the separator changes to ";" so you can use Windows paths with drive letters (e.g. "C:\foo;D:\bar"). This was done to help get some of the unit tests running on Windows. Note that this is a backwards-incompatible change, but given this feature was so limited on Windows I don't think anyone will mind. - Fixes and tweaks to get the unit tests working on Windows. There's one more thing I'm still trying to fix, but might not be ready for 1.1.5: - I'm trying to get PyXB to be consistent about it's output. Currently it's impossible to reliably reproduce PyXB bindings, since PyXB seems to regularly re-order it's output and renumber anonymous types. So to get a reproducible build the generated PyXB bindings have to be checked in to version control, and checking in generated files isn't nice. It's also impossible to look at diffs between different versions of the bindings, because there can be huge differences even if they were generated from the same XSD and have the same effect. Kind regards, Jon |
From: Peter B. <bi...@ac...> - 2012-06-28 10:47:13
|
A recent reported bug (https://sourceforge.net/apps/trac/pyxb/ticket/153) is: A mixed element with a sequence of <xs:any> moves all of the embedded text to the end: <v>Test <xhtml:b>something</xhtml:b> else<v> becomes <v><xhtml:b>something</xhtml:b>Test else</v> This isn't so much a bug as a design decision. I'm opening up discussion on how to resolve this. The issue is that the PyXB representation of a complex element is an instance of a Python object. XML attributes and elements are named, and are naturally represented as attributes on that object. Non-element content doesn't have a natural home. In the case of simple elements, the element itself holds the value, and is an instance of a (subclass of a) Python type rather than an object. If it's a complex type with simple content, there's a value() method on the object which distinguishes the content from any attributes. For complex elements with mixed content, PyXB attempts to maintain a list of element and non-element content, in the order it was added, in the content() function (http://pyxb.sourceforge.net/api/pyxb.binding.basis.complexTypeDefinition-class.html#content). When validation is in force, though, the generated DOM representation does not necessarily maintain this order (it cannot if the order would not validate). Consequently, there's no way to preserve the order of non-element content, and the mixed content gets emitted in a lump at the end (if at all, as with ticket 154). A similar issue exists with multiple-occurrence xs:any, because once PyXB has demultiplexed the element content into the correct fields in the containing instance, the original order has been lost. I would like to fix this, and there's an opportunity because the switch to counter automata required by a fix to #112 will completely replace the underlying content model, and the potential exists for preserving mixed content in order. What I don't see is that there's an obvious Python interface. I'm already unhappy about having to use names like "content" and "value" within the namespace of a complex or simple type to provide access to information like this, since that requires that XML attributes and elements with these names be renamed in the binding to eliminate the conflict. I'm also reluctant to have PyXB attempt to remember and preserve the original order of content, since that can take a lot of space, normally isn't needed, and can be invalidated due to manipulations of the Python instance. So the questions: * If an XML element has mixed content, how do you want to interact with it in Python? * If an XML schema does not impose an order on child elements, viz by using xs:choice or xs:any instead of xs:sequence, how much of a memory or performance penalty are you willing to pay to preserve the original document order? |
From: Peter B. <bi...@ac...> - 2012-06-15 23:55:32
|
I can't tell for certain, since I've got so much PyXB stuff lying around I'm not always sure Python isn't finding the wrong stuff, but I believe PyXB is now compatible with easy_install. easy_install --install-dir=/usr/local/lib/python2.7/site-packages --script-dir=/usr/local/bin PyXB did download and stuff the thing where I told it to, and I seem to be able to run the real test suite without having to do anything special. Could somebody confirm this so I can close out #130, or provide details on what issues remain? Thanks. Peter |
From: Peter B. <bi...@ac...> - 2012-06-15 20:50:00
|
Key features of the release: * A large number of bug fixes, especially in the area of internationalization. Naive uses of unicode have mostly been eliminated. * Corrections and improvements to date and time-related types, especially with respect to timezones. * More namespaces have been added in the common, WS-*, and OpenGIS bundles. * This release eliminates the separate packages for different bundles; all bundles and documentation except for OpenGIS are incorporated into the release file. OpenGIS is present but must be built manually. For more details, see http://pyxb.sourceforge.net/releases.html#jun-2012 As usual, questions here and bug reports on the trac page. http://sourceforge.net/apps/trac/pyxb/ Peter |
From: Peter B. <bi...@ac...> - 2012-06-14 20:02:09
|
The material in the next branch of the git repository is at the feature-freeze point for 1.1.4. It's been a frantic rush over the past few days to fix a stack more issues related to unicode, but I believe this has been done without breaking anything that used to work. There are one or two that I can't fix quickly, so a 1.1.5 will appear relatively soon, I hope. If you have a chance, retrieve the current version with: git clone -b next git://pyxb.git.sourceforge.net/gitroot/pyxb/pyxb Note that opengis bindings are no longer automatically built; there's a README in the bundle directory that explains how to fix that. There's also a really cool (albeit trivial) example of a Japanese python script using a Japanese extension to the OpenGIS GML bindings. See https://sourceforge.net/apps/trac/pyxb/ for the list of reported and fixed bugs. If you run into problems, file a ticket there; if it's a showstopper it'll get fixed, otherwise it'll have to wait for 1.1.5. I'll be working documentation, release notes, and packaging the rest of today and some of tomorrow, with the expectation of posting a new release before the weekend. Peter |
From: Peter B. <pa...@us...> - 2012-06-12 13:27:12
|
Yes, I'll be working PyXB the remainder of this week, and 1.1.4 should be out by Friday. Chances are it'll be in the same format as 1.1.3; I'll work to address the installation issues in a subsequent release (hopefully soon after 1.1.4, and probably without any more significant enhancements over 1.1.4). Peter On Tue, Jun 12, 2012 at 6:19 AM, Sebastian Annies <seb...@us...> wrote: > Hi Peter, > > you fixed a lot of bugs since your last 1.1.3 release. Would you mind to build the 1.1.4 > release so we can benefit from your bugfixes? > If there is anything you need help with I hereby volunteer. > > Best Regards, > Sebastian > > -- > This message was sent to your SourceForge.net email alias via the web mail form. You may reply to this message directly, or via https://sourceforge.net/sendmessage.php?touser=512948 > To update your email alias preferences, please visit https://sourceforge.net/account |