After discussing this around the office, we would be happy to see the three different attributes of nearest, floor and ceiling included. It would clear up any ambiguity and would be simple to implement support within the Janus software with no significant change in performance.
Giovanni, you are right in saying that as long as it is clear what an attribute represents the data can be structured appropriately. With that though, minimising the amount of premanipulation of data is ideal. Once changes to the dtd are finalised, we will be updating Janus and re-releasing it. In the meantime, I am preparing a release package for the current dtd implementation that should be available by end next week. Geoff -----Original Message----- From: Giovanni A. Cignoni [mailto:[EMAIL PROTECTED] Sent: Tuesday, 3 July 2007 12:11 AM To: Bruce Jackson; Brian, Geoff Cc: simstds@larc.nasa.gov; Hill, Shane Subject: Re: [fs] Re: Discrete interpolation attribute > So now I'm considering the following, and would appreciate any > feedback from the community: > > Instead of a single 'discrete' attribute, provide for three: > > 'nearest' which performs as Geoff described above (not how my diagram > is drawn) 'floor' which holds the previous dependent value until the > next breakpoint is reached (which matches my diagram above) 'ceiling' > which rounds up the next dependent value upon passing each breakpoint. > > This seems to be the most flexible, but perhaps also the most complex > and may not be worth the effort. >From my perspective, first of all it's a matter of ambiguosness of the modelling language. The really important thing is to agree on the way the function is calculated. A minimal solution is to allow just one attribute. If the way the table is interpreted is clear for all users, the language is safe. For instance, if the modeller first intention was to use a "nearest", but the language features the "floor", then the modeller has to arrange a little the table. The important thing is the modeller being aware that the language offers "floor". A little more work, but not an actual obstacle. The proposed solution of three attributes is more friendly. It costs a bit more because a fully compliant implementation of the language must offers the three ways of discrete interpretation of the table, but actually it doesn't seems a big costs - quadraticSpline and cubicSpline options are more demanding for the implementor :) Ciao, Giovanni Cignoni. IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email.
