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

-- 

Dave Kuhlman
http://www.davekuhlman.org

-- 

Dave Kuhlman
http://www.davekuhlman.org

------------------------------------------------------------------------------
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

Reply via email to