Juha,
Looking at this: https://www.w3.org/TR/xmlschema-0/#any
Here is a possible solution, though not a very slick one, I'll
admit:
1. When we parse the XML instance document, we convert the `xs:any`
element to a unicode string and save string as the internal
representation: To do so, the generated code would use this:
def gds_build_any(self, node, type_name=None):
content = etree_.tostring(node, encoding="unicode")
return content
And, the build method would do:
content = self.gds_build_any(node)
self.content = content
2. And, the `exportChildren` method would do:
content = etree_.fromstring(self.content)
outfile.write(content)
3. And, when users want to write code that use that content, because
they'd know what the structure of that specific `xs:any` element
is, they could do something like the following:
node1 = etree_.fromstring(self.content)
# The next line must be tailored to the specific structure
# of the xs:any element.
node2 = node1[0] # or: node2 = node1.getchildren()[0]
content = node2.text
Would that be a reasonable solution? If so, I'll try adding code
that generates the code that supports it.
I'll experiment with it a bit. Maybe I can come up with some code
that you can try.
Wait a minute. I've got something. And, it seems to work. I've
attached it to a separate email.
My testing shows that we're very close. There are some small
differences between `soapinvocie.xml` and the content that the
generated module exports after parsing it. For example, (1) some
special characters that are converted from the "&#nnn;" form into
multi-byte characters and (2) some numbers that have a trailing dot
added (looks like they are instances of an `xs:simpleType` that is a
restriction on `xs:decimal`, which are supposed to be real numbers)
etc. You will need to tell me whether those differences matter.
I'll do some more testing.
Dave
On Fri, May 10, 2019 at 02:07:34PM +0300, Juha Tuomala wrote:
>
> On Tuesday, 7 May 2019 07:19:25 EEST Dave Kuhlman wrote:
> > I think you are likely right to focus on that xs:any definition
> > inside the CustomContent. Normally, the code generated by
> > generateds has to know what kind of object it is supposed to build
> > at any given point in the object tree, and when it does, it builds
> > an instance of a generated Python class. Using xs:any effectively
> > says: "I don't know which kind of object to build.
> >
> > I'll look into it.
>
> > Unfortunately, tomorrow I take off for a week of travel any
> > vacation. So, it might be a few days before I work on this.
> >
> > If you learn anything more, please pass it along. And, I'll do the
> > same.
>
> see my comments
>
> https://stackoverflow.com/questions/56005920/generateds-stops-processing-child-elements
>
> GDS is well aware of any-beast, it just skips it without creating class-
> mappings.
>
> I'm just not sure where/how there is a definitions for
> - basic xml-schema types (xs:string, xs:boolean etc)
> versus
> - parsed schema structure
>
> I guess it's in the generateDS.py code, in sax-handler?
>
> Giving a name and type for each element obviously makes a difference too.
>
> Much easier digging into this kind of project if one has himself gradually
> written the whole code, hopping into end result is somewhat difficult.
>
>
>
> Juha
>
> --
> t...@iki.ee | http://tuju.ee | sip:t...@iki.ee | +3726311345 | +3725025337
> Better to have one, and not need it, than to need one and not have it.
>
>
--
Dave Kuhlman
http://www.davekuhlman.org
_______________________________________________
generateds-users mailing list
generateds-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/generateds-users
