New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Simplify XML description of model variables #514

Open
t-sommer opened this Issue Dec 18, 2018 · 2 comments

Comments

Projects
None yet
3 participants
@t-sommer
Copy link
Collaborator

t-sommer commented Dec 18, 2018

Currently the type specific information of the variables is stored in a nested tag inside the <Variable> tag e.g.

<ModelVariables>
  <Variable name="v" valueReference="1" description="Velocity">
    <Float64 start="0.0" unit="m/s"/>
  </Variable>
  <Variable name="gear" valueReference="2" description="Gear number">
    <Int32 start="1"/>
  </Variable>
</ModelVariables>

However the same information could be stored as

<ModelVariables>
  <Float64 name="v" valueReference="1" description="Velocity" start="0.0" unit="m/s" />
  <Int32 name="gear" valueReference="2" description="Gear number" start="1" />
</ModelVariables>

which results in a more compact XML and provides better readability.

@KarlWernersson

This comment has been minimized.

Copy link
Collaborator

KarlWernersson commented Dec 19, 2018

In fmi 2 we have 7 attributes that are common for all variable types and they are stored in scalarSariable
Then the scalar variable has a one type node that contians type specific attributes which varies in number from 12 in Real, and 2 in Boolean and String. As you propose this can be flattened in wich you would get for Fmi 3.0 11 (if I counted right) different kinds of variables, instead of one variables with 11 different kinds of types.

I don't currently see any great benefit of doing it one way or another, its more a matter of taste. But since we have had it hierarchical in FMI 1.0 & 2.0 I would prefer not to change it unless we have a good motivation for it.

@chrbertsch

This comment has been minimized.

Copy link
Collaborator

chrbertsch commented Jan 11, 2019

Discussion in Meeting 11.1.2019
Andreas P.: Is this really important or only a matter of taste?
Pierre: We touch the variables anyway
Andreas P.: With FMI 3.0 we wanted to stay close to FMI 2.1. We spend a lot of time on such issues
Pierre: If we want to do it, we must do it now. Benefit: XML smaller; in the past we saw performance limitation in implementations. That part of the XML schema is changed anyway.
Klaus: Is it really simpler? E.g. for the units?
Pierre: ... (subtypes)
Karl: Do not see the benefit
Torsten S: Saves 2/3 of the file
Kaska: agree
Torsten B: That's why we put it in a zip
Andreas J: This goes beyond beauty, but efficiency. Could make sense regarding clean-up. But will create more effort for people already creating prototypes
Pierre: Agree.
Karl: Type definition in the XML schema has also to be touched.
Andreas J: We are just moving around information in the XML.
Pierre: can be done.
Karl: Still do not see the need
Pierre: Types can still be done the same way.
Masoud: the old definition has the advantage that in the future we could define structures
Andreas J: Not with me being around
Klaus: XML is for structure; looks weired that we remove structure from structure
Kaska: We would remove unneccessary structure
Torsten: I implemented three different implementations, the effort is minimal
Karl: if one has not a good reason, do not change
Torsten: Just remove an unnecassary layer

Poll: (weights from -10 to 10)

Pro:
Kaska (8), Andreas J. (3), Pierre (8), Christian (5), Meik (5), Masoud (5), Torsten S (10)
Contra:
Karl (-9), Andreas P (-9), Thomas B (-9), Antoine (-10), Klaus (-1)
Abstain

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment