Gérard,
Here is what I've done on the decimal and formatting issue you
describe below:
1. I've reworked the GeneratedsSuper class so that it has methods
`gds_parse_xxx`, `gds_validate_xxx`, and gds_format_xxx` for each
of string, integer, float, and decimal simple types.
2. I've changed the generation of the build and export methods so
that the `gds_xx_yy` methods are called for the above simple types.
3. I changed the `gds_parse_decimal` method so that it creates and
instance of `decimal.Decimal`.
4. I changed the `gds_format_decimal` method so that it uses the
format "%0.10f" and applies `.rstrip('0'). With that format and
rstrip, 12.34 will write out "12.34".
You can override some of the above in a class `GeneratedsSuper` in an
importable module `generatedssuper.py`, but I'm hoping these
"defaults" will do what you need. If not, please let me know. And,
I'd be interested any other comments that you have.
Question: If the value read from an XML instance document is
"12.340", do we need to preserve the trailing zero on export? The
above changes do not do that.
I've pushed these changes to Bitbucket (but have not yet created a
release at pypi.python.org).
Dave
On Fri, Feb 01, 2019 at 01:40:00PM +0100, Gérard Yin wrote:
[snip]
>
> 2. For the second one, my gut feeling is that allowing people to opt-in to
> map xsd:decimal into Python's Decimal would be a good thing.
> To be honest, I had in mind something simpler than setting up a
> generatedsimportnamespaces.py.
> My initial thought would have be creating a command line option, as it is
> also easier to document. But as long as it works, I guess I'm fine.
>
> Rationale for using Decimal is that some xsd designers use xsd:decimal to
> allow storing a version number of phone number.
> This design choice may be arguable, but in this case I can't do much about
> it.
> Using float in this case means that version number 1.20 may be exported as
> 1.2 or 1.199999999999, and that a phone number 123456789 may be exported as
> 123456789.0
>
> Thanks
> Gerard
>
[snip]
> On Fri, Feb 1, 2019 at 12:45 AM Dave Kuhlman <dkuhl...@davekuhlman.org>
> wrote:
>
> > Gérard,
> >
> > Good to hear from you. And, you are welcome and thank you for your
> > suggestions.
> >
> > A few comments:
> >
> > 1. I suppose we can call the `xs:include` and `xs:import` problem a known
> > issue. Worse yet, it's seems to be an unsolvable one. Without
> > looking at your XML schema, I cannot be sure, but it's likely
> > that the problem results from there being `xs:complexType`
> > definitions in two separate namespaces with the same
> > (unqualified) name. `generateDS.py` trying to generate a Python
> > class for each `xs:complexType` (that is, for each element type)
> > and, because to does so in a single Python module, something is
> > going to go wrong.
> >
> > If this is your case, you might want to look at the use of the
> > following command line options (when you run `generateDS.py`):
> >
> > --one-file-per-xsd Create a python module for each XSD
> > processed.
> > --output-directory="XXX" Used in conjunction with
> > --one-file-per-xsd.
> > The directory where the modules will be
> > created.
> >
> > It's not an effort-free solution, but in some cases it might
> > help.
> >
> > If you think you error is different from this, please let me
> > know. Or, maybe you could give me access to the XML schema that
> > produces the problem.
> >
> > 2. Recently, I've had someone else question the choice of formatting
> > options for the export of numeric types. In particular, this
> > other user suggested that we generate code that exports elements
> > define as simple type double with the use of "%f" rather than
> > "%e".
> >
> > Am I correct that it's the formatting used during export that is
> > the problem? Or, is it the internal Python data type, itself
> > that you believe needs to be changed?
> >
> > You can find some information about this here:
> >
> > -
> > https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#decimal
> > -
> > https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#float
> > -
> > https://www.w3.org/TR/2004/REC-xmlschema-2-20041028/datatypes.html#double
> >
> > I'm looking at the above document where it describes the "Lexical
> > representation for each of the above. It appears that that doc
> > is saying that we should be using the following when exporting
> > each of the above types:
> >
> > Schema Export Internal Python
> > XML type format representation
> > -------- ------ -----------------
> > decimal %f decimal.Decimal
> > float %E float
> > double %E float
> >
> > I do not see anything in the XML schema description of the
> > decimal simple type that suggests exact precision, which
> > apparently is what you get when you use Python's
> > `decimal.Decimal`. In fact the XML schema document says: "the
> > number 2.0 is not distinct from the number 2.00". But, using
> > `decimal.Decimal` is fine with me. I do not have an opinion, one
> > way or the other.
> >
> > And, it seems that the user should have some control over this.
> >
> > Do we need to take a vote? Should we have another command line
> > option? Should it be configurable at run-time, for example by
> > adding options to the file `generatedsimportnamespaces.py`? If
> > this last, "generatedsimportnamespaces" will turn out to be an
> > awkward name for that module. Still, suppose we add a table (a
> > Python dictionary) as an optional item in that file, and the
> > dictionary might look something like this:
> >
> > GenerateDSbuiltintypes = {
> > "float", ("float", "%E"),
> > "double", ("float", "%E"),
> > "decimal", ("decimal.Decimal", "%f"),
> > }
> >
> > What do you think?
> >
> > Another thought -- Maybe we should be able to use a file
> > containing the same set of tables to set the default values at
> > generation time, that is, when `generateDS.py` itself is run.
> > Our logic might be the following:
> >
> > 1. For each of the data types `xs:float`, `xs:double`, and
> > `xs:decimal` there are default values for building and
> > formatting.
> >
> > 2. Those default values can be overridden at module generation
> > time by providing an importable module
> > ``generatedsimportnamespaces.py`` that contains any of the
> > specified tables.
> >
> > 3. And, further, the same values can be overridden at (user)
> > run-time (when the generated module is run or imported) by
> > providing an importable module
> > ``generatedsimportnamespaces.py`` that contains any of the
> > specified tables.
> >
> > OK. I've started doing a little work on this. I've made some
> > progress on some parts of it and still need to think through
> > other bits. I'm hoping that I'll have something that I can show
> > you next week sometime.
> >
> > If you have comments or suggestions, I'd be happy to hear them.
> >
> > Dave
> >
> > On Wed, Jan 30, 2019 at 06:36:38PM +0100, Gérard Yin wrote:
> > > Hi Dave,
> > >
> > > Just wanted to give some comments about generateDS.
> > >
> > > First of all, thanks a lot for providing this software, which proves
> > really
> > > useful.
> > >
> > > During my use of the tool, I found the following issues:
> > >
> > > 1. When a xsd does a <xs:include> but the namespace prefix is different
> > > between the parent and included schema, generateDS fails to generate the
> > > bindings. (For example parent has xmlns:xs="
> > http://www.w3.org/2001/XMLSchema";
> > > but child has xmlns:xsd="http://www.w3.org/2001/XMLSchema"; ). I haven't
> > > really tried to look at the problem origin in the source code, but
> > > realigning the prefixes solves my issue)
> > > 2. I am wondering why you treat xs:decimal type as a Python float. On my
> > > side, this generates all sorts of rounding issues, unexpected decimal
> > > places appearing when exporting. Trying to fiddle with the source and
> > > replacing use of float from Python's decimal.Decimal whenever DecimalType
> > > occurs seems to fix my problem. I'm wondering if I missed anything.
> > >
> > > Have a nice day
> > > Gerard
> >
> > --
> >
> > Dave Kuhlman
> > http://www.davekuhlman.org
> >
--
Dave Kuhlman
http://www.davekuhlman.org
_______________________________________________
generateds-users mailing list
generateds-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/generateds-users
