> Hi Dave,
>
> Here I am again - internally I cannot get the previous problem solved
> (various xsd declarations of the same type of element) -sigh-. Some
> developers say that the time-effort versus the gain is too low... -sighs
> again-
Mikki,
Good to hear from you again.
That's always a consideration, of course. The mission for
generateDS.py is to save you time and enable you to get something
done more quickly. If it does not do that (for example, because of
it has problems with your schema), you should go with what enables
you to get your job done.
And, by the way, if you have comments about why it's not as helpful
as you hoped, I'd be interested in them.
More below ...
>
> Anyhow; I ran into another quark in our code. It seems that we made some
> workarounds for getting various elements from our response xml - which all
> appear to be <xs:simpleType>'s.
> What is your recommendation to get this information from the model?
>
> Below is what I did:
> Generated model from xsd; where there are a few simpleType's -> for
> example for <Version>x.y</Version>. (I used GenerateDS-2.12b)
> Parsed the xml into the model - and find out that [code]rootTag, rootClass
> = self.model.get_root_tag(rootNode)[/code]*returns [code]Version,
> None[/code]. Where I hoped it would return something like str...
>
> What I did find is the following:
> if rootClass is None:
> * * rootTag = 'Version'
> * * rootClass = xs_string
> - but the last line throws a 'NameError: name 'xs_string' is not defined'
> at me...
>
> I might be able to send you the xsd - when needed.
> Best,
I'm not sure that I understand the issue correctly. But, perhaps
the following might help:
You should be aware that when you generate modules from a schema
that contains xs:simpleType definitions, no classes are generated
for those simple types. For example, I've attached a sample schema.
It contains 3 xs:simpleType definitions and 1 xs:complexType
definition. If you generate a module, you will notice that there is
only one generated "representation" class (complex_type01).
However, when building from an instance document or exporting, it
does parse and format strings, integers, and floats, depending on
the definition of each simpleType.
Were you expecting it to do something different?
I'm groping here, and if I'm not mis-reading the problem, you may
need to give me more information.
Dave
--
Dave Kuhlman
http://www.davekuhlman.org
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema";>
<xs:simpleType name="simple_type01">
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:simpleType name="simple_type02">
<xs:restriction base="xs:integer"/>
</xs:simpleType>
<xs:simpleType name="simple_type03">
<xs:restriction base="xs:float"/>
</xs:simpleType>
<xs:complexType name="complex_type01">
<xs:sequence>
<xs:element name="string_value" type="simple_type01"/>
<xs:element name="integer_value" type="simple_type02"/>
<xs:element name="float_value" type="simple_type03"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
------------------------------------------------------------------------------
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
_______________________________________________
generateds-users mailing list
generateds-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/generateds-users
