OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xmile message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [xmile] default XML value proposal

Hi Karim,

I think I only explained half of what was in my head.  In the current spec, attributes that contain the default values are omitted from the generated XML file - avoiding clutter.  This is a good thing and I like it.

However, for attributes other than cascaded styles and boolean flags (which can be changed from show_* to hide_*), I see little benefit - most of these attributes are specific to the particular tag.  For example, on a <slider>, I don't see a big readability improvement by omitting min and max when there values are 0 and 1, respectively.  Essentially, I am suggesting that most tags are not inherited by other tags, and don't gain much by having some attributes hidden.  I am also specifically referring to xml attributes - not subtags, even though they are two sides of the same coin.

I am starting to come around to the idea that there needs to be a canonical xmile document with defaults, although I am still interested in seeing how much we can minimize this (maybe just using it for styles?), as the more we require the ability to omit/populate any attribute, the more complicated every implementation needs to be, the harder it is to adapt to the (changing) spec, and the more likely implementations are to diverge/introduce bugs.

As an example, right now (without correctly handing defaults) I can write out an in-memory data structure in 5 lines, with error checking:

output, err := xml.MarshalIndent(xmileInMemory, "", " ")
if err != nil {
log.Fatalf("xml.MarshalIndent: %s", err)
os.Stdout.Write([]byte(xmile.XMLDeclaration + "\n" + string(output) + "\n"))

I think properly omitting default values as currently specified is going to make that significantly longer.

On Mon, Sep 30, 2013 at 12:03 PM, Karim Chichakly <kchichakly@iseesystems.com> wrote:
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.


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.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]