On Sun, Mar 29, 2015 at 02:08:32PM +0200, Jan Biel wrote: > On 28.03.2015 00:53, Dave Kuhlman wrote: > > On Thu, Mar 26, 2015 at 11:40:49AM +0100, Jan Biel wrote: > >> Dear Mr. Kuhlman. > >> > >> Thanks for your work and effort on building and maintaining the very > >> useful GenerateDS tool. > >> > >> I have a question and would be happy if you could find the time to reply: > >> > >> My xsd schema uses elements that are both optional and have a default > >> value, e.g. > >> <xs:element name="Value" type="xs:float" default="0.0" minOccurs="0"/> > >> > >> When reading and saving a corresponding xml file where the optional > >> element is missing, GenerateDS will always add the missing element, > >> using the default value. Is this behavior desired? If the element > >> was not there before, shouldn't it be omitted when the document is > >> saved? If this behaviour is intended, would you know of a way to > >> preserve the original state of the document? I found a workaround > >> by manually replacing the default values by ‘None’ in the generated > >> python code: > >> > >> def __init__(self, Id=0, Value=0.0): > >> def __init__(self, Id=0, Value=None): > >> > >> However, since the document is fairly large and there would be many > >> occurrences, I was hoping there was a better way to automate this. > > So, if I understand you correctly, you are saying that in the > > generated method exportChildren, for an element with a default > > value, instead of generating: > > > > if self.integer_value is not None: > > if self.string_value is not None: > > > > We should instead generate: > > > > if self.integer_value != 27: # or some default integer value > > if self.string_value != "some default string value": > > > > Etc. > > > > And, the generated function hasContent_ would also need to be > > changed in a similar way. > > > > That sounds right to me. Do you agree? Or, is there some corner > > case that we have to consider? > > > > Unfortunately, the code in generateDS.py will need to be modified in > > a number of places, because it has to handle types xs:string, > > xs:integer, xs:date, xs:float, etc. So, this change will take me a > > bit of time. > > > > I'll see what I can do. > > Hello again, thanks for the prompt reply. > > I'm not sure I understand what you mean quite right. I probably > explained it poorly. > > It seems like your proposal would remove an attribute if it is equal to > a predefined default value. > That wasn't quite what I had in mind. > > In my case, if an element is optional and has a default value in the > schema _and_ the attribute is missing in the xml, I would expect that > the element would be omitted in the converted version.
I believe we are moving in the same direction. I agree that, as you say, if an element has a default value in the schema and is missing in the input XML instance doc, then it should be omitted when exported. In addition, if the element is present in XML instance doc and its value is later changed so as to be equal to the default value, then it also should be omitted from the output. And, now I have made analogous changes for the generation of the method hasContent_ in each class and for the export of attributes (in addition to elements). [More below] > > I replaced > > def __init__(self, Id=0, Value=0.0): > > with > > def __init__(self, Id=0, Value=None): > > and that seems to work. In the first version, a missing element would be > added with an element of value 0.0, while in the second version a > missing element would still be missing when saving the file, which is > kind of what I would expect. > > Maybe the following clears up a bit more what I had in mind. If I am not > mistaken, all cases are currently implemented as outlined below, except > the one in red. That is the case I was talking about before. > > *case 1:* > xsd: element optional, no default value given > xml: element missing > --> output: element missing > > *case 2:* > xsd: element optional, no default value given > xml: element exists > --> output: element is unchanged > > <red> > *case 3:* > xsd: element optional, default value given > xml: element missing > --> expected output: element missing > --> current output: missing element is added with default value > </red> > > *case 4:* > xsd: element optional, default value given > xml: element exists > --> output: element is unchanged > > *case 5:* > xsd: element mandatory, no default value given > xml: element missing > --> error on reading xml > > *case 6:* > xsd: element mandatory, no default value given > xml: element exists > --> output: element is unchanged > > *case 7:* > xsd: element mandatory, default value given > xml: element missing > --> output: missing element is generated with default value > > *case 8:* > xsd: element mandatory, default value given > xml: element exists > --> output: element is unchanged > Thank you very much for this set of test cases. Good idea. I wish I'd thought of that. I've created an XML schema and an XML instance document that attempts to implement them. In a separate email (so as not to burden the generateds-users list with too much bulk), I've attached a schema (test02.xsd) and an instance doc (test02.xml) for your cases and also a patched version of generateDS.py that handles them correctly, I believe. Also attached is a module (tmp05sup.py) generated from test02.xsd by the new, attached version of generateDS.py. The one disagreement I have is with cases 5 and 7. In both of these the element is required but missing. That's an error, and I don't think we should be trying to make the code generated by generateDS.py either validate for those errors or fix them up. I believe what we want to do with those cases is to use schema validation application (for example, xmllint or one implemented with lxml) and fix up the XML instance doc. If you feel that this is an issue, we could consider an enhancement to the generated code that would support optional validation. The idea would be that when you run the generated code and supply a command line option (say "--validate=myschemafile.xsd"), it would do validation before attempting to parse the XML instance doc. Since it's easy enough to run xmllint as a separate step, I believe that's over-kill. What do you think? I've also attached a simple validation program implemented with lxml. See the following for more on this: http://lxml.de/validation.html. You can see that it would be quite easy to build this into your own application if you needed it. Although, xmllint is better in the sense that it reports multiple errors. > So basically what I am saying is: > Only generate a default value if it is mandatory and missing. > If it is optional and missing, it should be missing in the output. I agree. But, also generate it if there is a default value and the actual value is different from the default value. I believe that the version of generateDS.py that I have attached behaves consistently with the above. But, I do have more testing yet to do. Thanks much for you help with this. I'll be back soon when I have these changes more firmed up, more testing done, etc. If you disagree with any of the above or think I've gone astray in some way, please let me know. Dave > > My goal is to make sure that a valid xml document can be loaded and > saved by the generated code and the saved version looks identical to the > original. Currently that is not the case since missing optional elements > are not left missing, but instead new elements with the default value > are added. > > Thanks a lot for caring about this. > If there is more to clear up, please let me know. > > Cheers, > Jan Biel -- Dave Kuhlman http://www.davekuhlman.org ------------------------------------------------------------------------------ Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ generateds-users mailing list generateds-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/generateds-users
