Re: [xmile] default XML value proposal

The purpose of the default values is to avoid cluttering the XML file with lots of attributes when the majority of objects use the same value. This dramatically increases readability and also reduces the file size.

The default values do not have to be implied. We can define a XMILE-wide style sheet that contains all the default values and we probably want to do this so we both are explicit about them and have a single place to review them. It can also help the implementation by automatically providing the defaults when attributes are added to the spec.

It is true it would not hurt to reverse the sense of some of the boolean values that now default to true. In the display especially, these are (unfortunately) historic rather than carefully conceived. Changing a "show" tag to a "hide" tag is pretty clear and not a major change. I believe there are some cases, though, where it may be harder to come up with a meaningful name. I am also pretty sure that we cannot default numbers to zero in all cases, but we can look into it.

As we think about these changes, we should also consider the impact on converting existing XMILE models. Broad changes will make this more difficult than minor changes.

Karim

On Mon, Sep 30, 2013 at 10:26 AM, Bobby Powers <bpowers@iseesystems.com> wrote:

Hi folks,

I've been working on implementing XMILE and have run into a few minor snags.

First, there is an idea that attributes have a default value. I would like to propose that all default attributes for numbers and booleans be 0/false. My implementation uses reflection to marshal XML into structures - it becomes hard to tell if an attribute was explicitly specified with a 0-value, or was omitted in the XMILE file in some parts of the current spec. I think that changing options from, e.g. 'show_background' (with a default of true), to 'hide_background' (with a default of false) will make implementations easier and lower the cognitive load when visually inspecting XMILE files. This idiom appears most often in the <display> tags, but is sprinkled elsewhere too (such as an aux's flow_concept=true).

Without this, it becomes very difficult to build a parser for XMILE without hand-coding the XML read/write.

I'll have more to share in a few days, but thoughts and concerns about the above are welcome.

yours,
Bobby

xmile message