Thanks Dave,
For the first issue, I had a look at the schemas, and there are no complex
type defined twice in two files.
I don't think I have the right to communicate the schemas, so will try to
isolate the problem when I have time.
What I could say so far is the stack trace at generation time is the
following:
Traceback (most recent call last):
File "/Users/gyin/anaconda3/bin/generateDS.py", line 7758, in <module>
main()
File "/Users/gyin/anaconda3/bin/generateDS.py", line 7740, in main
superModule=superModule)
File "/Users/gyin/anaconda3/bin/generateDS.py", line 7209, in
parseAndGenerate
prefix, root, options, args, superModule)
File "/Users/gyin/anaconda3/bin/generateDS.py", line 7019, in generate
generateFromTree(wrt, prefix, elements, processed)
File "/Users/gyin/anaconda3/bin/generateDS.py", line 6882, in
generateFromTree
generateClasses(wrt, prefix, element, 0, nameSpacesDef)
File "/Users/gyin/anaconda3/bin/generateDS.py", line 5220, in
generateClasses
generateCtor(wrt, prefix, element)
File "/Users/gyin/anaconda3/bin/generateDS.py", line 4361, in generateCtor
fullyQualifiedType = attrDef.getFullyQualifiedTypeName()
File "/Users/gyin/anaconda3/bin/generateDS.py", line 1490, in
getFullyQualifiedTypeName
return prefixToNamespaceMap[prefix] + ":" + value
KeyError: 'xsd'
and my main xsd starts as follows:
<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns="http://namespace.org"; xmlns:xs="
http://www.w3.org/2001/XMLSchema"; targetNamespace="http://namespace.org";
elementFormDefault="qualified" version="6.000" id="id">
<xs:include schemaLocation="included.xsd"/>
and included.xsd starts as follows:
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema";
elementFormDefault="qualified" attributeFormDefault="unqualified"
version="6.000" id="id">
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
On Fri, Feb 1, 2019 at 12:45 AM Dave Kuhlman <[email protected]>
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
>
_______________________________________________
generateds-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/generateds-users
