The QName problems with PyXB have been fixed on the next branch of the repository at https://github.com/pabigot/pyxb/commit/eb61be926da2d90908d8f82d0dac1c142e0088fe. Still available on Sourceforge at https://sourceforge.net/p/pyxb/code/ci/next/tree/ but as prophesied active development and ticket management has switched to github: https://github.com/pabigot/pyxb
This change requires that all bindings that use QNames as data objects must be rebuilt. OpenGIS bindings in particular must be rebuilt, and the change to how QNames are used to look up components is likely to affect WSDL applications. All legacy SourceForge tickets (https://sourceforge.net/p/pyxb/tickets/) that are likely to ever be worked have been added on github (https://github.com/pabigot/pyxb/issues?page=1&state=open). If there are tickets you care about that I didn't transfer, please feel free to add a new issue. Anybody tracking development, please try this. I anticipate PyXB 1.2.4 release in mid July; no significant features/bug fixes are pending for that release, just some cleanup and anything reported by users. Peter On Thu, Mar 6, 2014 at 8:21 AM, Peter Bigot <big...@acm.org> wrote: > Not so great news, I'm afraid. > > This turns out to be a really nasty thing to fix, as it requires > propagating namespace contexts into areas that they've never had to > reach before (you can't form the lexical representation of a QName > without a context that tells you how to spell the qualifying prefix > for the QName's namespace). > > I'm not going to be able to develop a satisfactory solution in a few > hours, so I'm going to have to delay this until I can find a spare > week or two when I can address the accumulated infoset issues behind > this and a couple other bugs. That won't happen until I've found a > source of income for this year. > > Sorry. No estimated date for a fix, and there will be no PyXB > releases until there is a fix. > > Peter > > > On Wed, Mar 5, 2014 at 4:24 PM, Xavier Fernandez > <xav.fernan...@gmail.com> wrote: >> Great news :) >> >> I'm looking forward to your bugfix. >> >> Xavier >> >> >> On Wed, Mar 5, 2014 at 4:44 PM, Peter Bigot <big...@acm.org> wrote: >>> >>> Heh. tns should not be special. It is special because PyXB has not >>> properly handled the QName type until you pointed this out: the value space >>> and lexical space are not the same. Since the schema for soap12 identifies >>> the enumeration restrictions with the string "tns:Sender" it works. Once I >>> correct PyXB to handle QName properly (making the type inherit from >>> ExpandedName instead of string), alternative namespace prefixes will also >>> work. >>> >>> This is now https://sourceforge.net/apps/trac/pyxb/ticket/229 and I should >>> get a patch into the next branch by the end of the week. >>> >>> Peter >>> >>> >>> On Wed, Mar 5, 2014 at 9:25 AM, Xavier Fernandez <xav.fernan...@gmail.com> >>> wrote: >>>> >>>> Hello list, >>>> >>>> I'm quite new to PyXB and I'm looking forward for the porting to Python >>>> 3. >>>> >>>> Meanwhile I've got an issue with soap 1.2 faults, is the 'tns' namespace >>>> magic or something ?: >>>> >>>> from pyxb.bundles.wssplat import soap12 >>>> >>>> resp="""<{0}:Envelope >>>> xmlns:{0}="http://www.w3.org/2003/05/soap-envelope";> >>>> <{0}:Body> >>>> <{0}:Fault> >>>> <{0}:Code> >>>> <{0}:Value>{0}:Sender</{0}:Value> >>>> </{0}:Code> >>>> <{0}:Reason><{0}:Text xml:lang="en">Reason >>>> test</{0}:Text></{0}:Reason> >>>> </{0}:Fault> >>>> </{0}:Body> >>>> </{0}:Envelope>""" >>>> >>>> soap12.CreateFromDocument(resp.format('tns')) >>>> print 'OK for tns' >>>> soap12.CreateFromDocument(resp.format('anything')) >>>> >>>> The CreateFromDocument works with 'tns' but not with 'anything' that >>>> fails with: >>>> pyxb.exceptions_.SimpleFacetValueError: Type >>>> {http://www.w3.org/2003/05/soap-envelope}faultcodeEnum enumeration >>>> constraint violated by value anything:Sender >>>> >>>> Am I missing something ? >>>> >>>> Regards, >>>> Xavier >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Subversion Kills Productivity. Get off Subversion & Make the Move to >>>> Perforce. >>>> With Perforce, you get hassle-free workflows. Merge that actually works. >>>> Faster operations. Version large binaries. Built-in WAN optimization and >>>> the >>>> freedom to use Git, Perforce or both. Make the move to Perforce. >>>> >>>> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk >>>> _______________________________________________ >>>> pyxb-users mailing list >>>> pyxb-users@lists.sourceforge.net >>>> https://lists.sourceforge.net/lists/listinfo/pyxb-users >>>> >>> >> ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ pyxb-users mailing list pyxb-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pyxb-users
