Andrii,
Thank you so much for your detailed testing and evaluation.
So, it looks like we are very close to having what we want.
See additional comments below.
Dave
On Tue, Dec 05, 2017 at 03:44:59PM +0000, Andrii Iudin wrote:
Hi Dave,
Thank you for preparing the new patch. I have tested it and the resulting
XML validates and fails validation as we would expect.
I am considering the following cases:
1) minOccurs="0"
no default value
actual value = None
Element not exported, the resulting XML is valid.
2) minOccurs="0"
no default value
actual value = 1
Exported, XML is valid.
3) minOccurs="0"
default value = 1
actual value = None
Not exported, XML is valid.
4) minOccurs="0"
default value = 1
actual value = 1
Not exported, XML is valid. This is analogous to your case 1. However, if
a user would just look at the resulting XML, how would they determine
whether there was a value provided that equals to the default one or not?
That is, how to distinguish this from case 3) ? It may not be crucial to
the user, though.
One possible solution, in an attempt to make as many people happy as
possible (although using the word "happy" in connection with XML
seems delusional) would be to add back in the command line option
(--export-when-default) that we tried in a previous fix. Then you
could generate code that always exports each child elemet, even when
(1) it is optional and (2) it has a default value and (3) the
default value is equal to the current value.
Quoting from an earlier message:
"Following your hint, I have added a new command line option to
generateDS.py: --export-when-default
"When you use this option, generateDS.py will now generate code
that exports children, even when a child's value is equal to the
default value specified in the XML schema."
Should I put that command line option back in or not? What do you
think and which would you prefer?
I've got back-up, so I can re-implement that feature quite quickly.
Additional, possibly confusing blather follows ...
(1) One point of view for this case is that we should give the
control by providing a command line option to generateDS.py that
causes it to generate code that exports child elements even when
they are optional and their value is equal to their default value.
(2) Another POV would be to say that if the use wants optional elements
(elements with minOccurs="0") and default values always to be
exported, then s/he should change the schema so that minOccurs >= 1
for that element.
(3) The second point (2) seems reasonable to *me*, but likely does
not to someone who is working with a schema that came from an
organization that s/he does not control. That user likely does not
want to be working with her/his special version of the schema, much
less having to update or merge these changes when a new version of
that schema arrives from that other organization.
(4) On the other hand, if we follow up on point (1) above, next
month, someone will tell us that they want this forced export to be
true of only some specific/specified elements inside of some other
elements, etc. Sigh.
Implementing point (1) above (the new command line option that
forces export of child elements that are optional and whose default
value equals their current value) is straight-forward, and it takes a
reasonably small amount of time.
Implementing point (4) above is something I would not know how to
approach without focus groups, questionnaires for users, etc.
If you think this feature would be usable at all, I'd vote for point
(1), that is, the command line option that forces export.
I'm open to suggestions. And, I'd like to hear whether that would
be useful in any of your own use cases.
Dave
5) minOccurs="0"
default value = 1
actual value = 2
Exported, XML is valid.
6) minOccurs="1"
no default value
actual value = None
Not exported, XML is invalid. This case corresponds to the point that you
have raised. It looks correct to me that the validation should fail since
the element is mandatory.
7) minOccurs="1"
no default value
actual value = 1
Exported, XML is valid.
8) minOccurs="1"
default value = 1
actual value = None
Not exported, XML is invalid. However, XML would validate if the exported
element is just '<framesPerImage/>'. Should this be the way to export in
case there is a default value and no actual one? For a comparison, case 6)
would still fail validation even with '<framesPerImage/>' present, since
the default is not set.
9) minOccurs="1"
default value = 1
actual value = 1
Exported, XML is valid. This is similar to your case 2.
10) minOccurs="1"
default value = 1
actual value = 2
Exported, XML is valid.
Please tell me if I have missed something. Overall, it seems to be working
as expected and just cases 4) and 8) are raising questions.
Best regards,
Andrii
On 01/12/2017 00:09, Dave Kuhlman wrote:
Andrii,
Attached to a separate email is a new version. This version
generates code that:
1. does not export the child element if the element is optional
(minOccurs="0") and the value of the element is equal to the
default value;
2. exports the child element if the element is required
(minOccurs >= 1) even if the value of the element is equal
to the default value.
One point to consider: if the child element does *not* have a
default value and is mandatory (minOccurs >= 1) and it has a value of
None (that is, it has not been given a value the overrides the value
given by the constructor of the class), then it will not be
exported. Actually, we can't export it, since we do not have a
value to export.
We may have to discuss this last point.
If the element has been created by parsing a file that contains it,
then it will have a value different from None and we're OK. And,
since it is mandatory, any correct file (i.e. file that validates
against the schema) should contain that element, and will therefore
be exported.
This makes my head hurt. Got to quit for today.
Please give me your comments and tell me how your testing goes with
this new version. Thanks in advance.
Dave
On Thu, Nov 30, 2017 at 05:07:12PM +0000, Andrii Iudin wrote:
Dear Dave,
Thank you for the promptly implemented patch. I have tested it and the
result with the switch "--export-when-default" does not fail xmllint
validation on framesPerImage anymore.
I have discussed this with my colleagues and your suggested alternative
looks reasonable. If the element has more than zero minOccurs, than it has
to be exported with the default value, otherwise if the minOccurs is zero,
then it can be omitted.
Best regards,
Andrii
On 29/11/2017 23:59, Dave Kuhlman wrote:
Andrii,
I've made a fix. It's attached to a separate email. I've done some
light testing and this change seems to work as I expect. But, maybe
what I expect is wrong.
However, before using that new version, please read my comments
below. I'm wondering whether I've made the correct fix. See
below.
Following your hint, I have added a new command line option to
generateDS.py: --export-when-default
When you use this option, generateDS.py will now generate code that
exports children, even when a child's value is equal to the default
value specified in the XML schema.
Am I correct that we should apply this new behavior to child
elements, but *not* to attributes? I did a little reading on this
and it appears that an attribute with a default value is optional
but that a child element with a default value and minOccurs greater
than zero is not.
If the above is correct, perhaps instead of a new command line
option, this new behavior (not omitting the child element) should
always be done, or at least it should be the default and the new
flag should generate code that has the old behavior (exports the
child element when the value equals the default).
So, here is an alternative:
For child elements defined with a default value, generate code that
(a) always exports the child element if it's minOccurs is greater
than zero and (b) if its minOccurs is zero (it is optional) exports
it only if its value is different from the default.
If we do this, then we can get rid of the --export-when-default
option in the patched version I'm sending.
What do you think?
Dave
On Tue, Nov 28, 2017 at 11:28:39AM +0000, Andrii Iudin wrote:
Dear Dave,
We are having a problem with exporting an element with a set default value.
The element in question is
<xs:element name="framesPerImage" type="xs:integer" default="1">
<xs:annotation>
<xs:documentation>Normally = 1.
Relevant for multi-frame direct electron detectors.</xs:documentation>
</xs:annotation>
</xs:element>
It seems to be exported only when its value is not equal to the default one
if self.framesPerImage != 1:
showIndent(outfile, level, pretty_print)
outfile.write('<%sframesPerImage>%s</%sframesPerImage>%s' % (namespace_,
self.gds_format_integer(self.framesPerImage, input_name='framesPerImage'),
namespace_, eol_))
As a result, xmllint fails to validate the exported XML since it is missing
framesPerImage element.
Please could you tell if there is a switch that could force exports of
elements if they have a default value? The relevant code seems to be
starting at line 2080
if default is None:
wrt('%s if self.%s is not None:\n' % (fill, mappedName,
))
else:
wrt('%s if self.%s != %s:\n' % (
fill, mappedName, default, ))
Many thanks and best regards,
Andrii
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
generateds-users mailing list
generateds-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/generateds-users
