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
From: Giovanni A. Cignoni [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 3 July 2007 12:11 AM
To: Bruce Jackson; Brian, Geoff
Cc: firstname.lastname@example.org; 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 :)
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.