Re: [Animl-announce] Re: [Animl-develop] Allowed Values in AnIML

[<Tho...@cr...>]

>Instead of multiple, single "AllowedValue" values, we might do better to=20
allow=20
>ranges of "AllowedValue" values.  For example, with temperature it would=20
be=20
>better to allow this "AllowedValue" to range between a minimum value and=20
a=20
>maximum value.  To specify a single value we would have to put the value=20
in=20
>both, Min and Max fields or maybe the Max field would be empty. But this=20
is a=20
>design detail that is not so important at this point.
>The usage of that could be for vendors to specify their devises in their=20
vendor=20
>extensions if they want.

>On another subtopic, shouldn't we add a flag (attribute) to=20
"AllowedValue" to=20
>reverse it's sense and let us list non-allowed values?
>This wouldn't cost us much, and it gives us more flexibility in designing =


>techniques. To promote better understanding, we might choose to rename=20
the=20


Hello Dominik,

I am concerned about this.=20


AnIML with the current technique definitions tries IMHO to reinvent the=20
wheel.
XSD already provides us with all kind of restriction specifications, but=20
instead of re-using them, you try to define a completely new vocabulary.

Burkhard? has justified a new vocabulary with the argument that the=20
technique definition files will be easier to understand than XSD for the=20
typical AnIML end user, but from this discussion I see, that instead of=20
keeping them simple, they will  become more and more like a full schema=20
definition, only with a different syntax.

Let me show you what I mean. I randomly picked up a parameter template=20
form the IR definition:

                        <ParameterBlueprint name=3D"SampleState" type=3D"st=
ring" modality=3D"required" maxOccurs=3D"1">
                                <Documentation>Physical state/preparation o=
f the sample.</Documentation>
                                <AllowedValue>Solid</AllowedValue>
                                <AllowedValue>Liquid</AllowedValue>
                                <AllowedValue>Gas</AllowedValue>
                                <AllowedValue>Solution</AllowedValue>
                                <AllowedValue>KBr Pellet</AllowedValue>
                                <AllowedValue>Powder</AllowedValue>
                                <AllowedValue>Nujol Mull</AllowedValue>
                        </ParameterBlueprint>

You have:

1) a new type definition in the attribute "type" where instead of using=20
the standard xsd:schema types you have nonstandard float32, float64.

2) an attribute "modality" which could be expressed like in XSD: minOccurs =

=3D 1 (required) minOccurs=3D0 (optional)

3) an enumeration of allowed values, which would be in XSD, something like
        <restriction>
                <enumeration>...
        </restriction>

4) a comment which would be in XSD: <annotation>



Indeed, many restriction facets are nice to have. I can add regular=20
expressions for example to the list.=20
If they were of marginal use, they would not have survived in the long=20
standardization process of XML schema. ;-)

So why don't you reuse the work that is already done?



Thomas Weber


---------------------------------------------------------------------------=
------------------
CREON=B7LAB=B7CONTROL AG=20
a subsidiary of Waters Corporation
Europaallee 27-29, D-50226 Frechen, Germany
Tel. +49 2234 9207 0
Fax. +49 2234 9207 99