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

[Dominik P. <dom...@ni...>]

Hi Thomas,
I can"t see the problem, the "allowed value" tag is now a couple months=20
ago in the schema and the discussion
was just to extend the tag to allow ranges of values instead of just one=20
value per tag. I actually think that the technique schema is pretty easy=20
to read, to understand and to use. I think I need to clarify that we use=20
an xml file in the end to define a technique like UV, NMR, MS,.... and=20
NOT  a schema. The meta data approach that we had was to describe the=20
technique definitions in xml and not in a hard coded schema which=20
wouldn't give us the possibility to create schema extensions without=20
reconstructing our software.

But let's go to your example:
see below...


Tho...@cr... schrieb:

>
>
> >Instead of multiple, single "AllowedValue" values, we might do better=20
> to allow
> >ranges of "AllowedValue" values.  For example, with temperature it=20
> would be
> >better to allow this "AllowedValue" to range between a minimum value=20
> and a
> >maximum value.  To specify a single value we would have to put the=20
> value in
> >both, Min and Max fields or maybe the Max field would be empty. But=20
> this is a
> >design detail that is not so important at this point.
> >The usage of that could be for vendors to specify their devises in=20
> their vendor
> >extensions if they want.
>
> >On another subtopic, shouldn't we add a flag (attribute) to=20
> "AllowedValue" to
> >reverse it's sense and let us list non-allowed values?
> >This wouldn't cost us much, and it gives us more flexibility in=20
> designing
> >techniques. To promote better understanding, we might choose to=20
> rename the
>
>
> Hello Dominik,
>
> I am concerned about this.
>
>
> AnIML with the current technique definitions tries IMHO to reinvent=20
> the wheel.
> XSD already provides us with all kind of restriction specifications,=20
> but instead of re-using them, you try to define a completely new=20
> vocabulary.
>
> Burkhard? has justified a new vocabulary with the argument that the=20
> technique definition files will be easier to understand than XSD for=20
> the typical AnIML end user, but from this discussion I see, that=20
> instead of keeping them simple, they will  become more and more like a=20
> full schema definition, only with a different syntax.
>
Burkhard and I have created 8 different tags to describe a technique=20
definition. I hope I didn't miscount.  In my opinion this shouldn't be=20
too complicated to use.

> Let me show you what I mean. I randomly picked up a parameter template=20
> form the IR definition:
>
>                         <ParameterBlueprint name=3D"SampleState"=20
> type=3D"string" modality=3D"required" maxOccurs=3D"1">
>                                 <Documentation>Physical=20
> state/preparation of 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:


So let's say you are a vendor and use a detector for measuring the=20
temperature, and you want to allow just a rang of values for measuring=20
the temperature, you are not able to restrict that with the=20
<restriction> and <enumeration> tags especially because they are just=20
for the use of schema definitions and not the result xml file. We don't=20
know the values and the names of the parameters and vectors at this=20
moment and this is one reason for our decisions to use the meta data=20
approach and not a hard coded schema approach.

>
> 1) a new type definition in the attribute "type" where instead of=20
> using the standard xsd:schema types you have nonstandard float32,=20
> float64.
>
Since we allowed float32 and float64 as a valid value for the result=20
data, we need to specify which precision is required for a specific=20
value. You must specify the type of specific value to verify data=20
precision and validation issues. And again we are talking about an xml=20
file not a schema(xsd) file.

> 2) an attribute "modality" which could be expressed like in XSD:=20
> minOccurs =3D 1 (required) minOccurs=3D0 (optional)
>
> 3) an enumeration of allowed values, which would be in XSD, something=20
> like
>         <restriction>
>                 <enumeration>...
>         </restriction>
>
> 4) a comment which would be in XSD: <annotation>
>
>
We need the <documentation> tag to give the option to document the=20
technique definition (in the xml file). Since the technique definitions=20
are in XML and NOT represented as a xsd (schema), how would you use the=20
<annotation> tags to document your specific parameter as a technique=20
domain expert in XML?

>
> Indeed, many restriction facets are nice to have. I can add regular=20
> expressions for example to the list.
> 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?
>
>
W3C recommends that tags be used only in the xml file if they have been=20
specifically defined in the schema. The alleged predefined tags that you=20
have mentioned are just for using in a schema and so they are in the end=20
unusable for that problems. We already use the=20
<xs:annotation>,<xs:documentation>,<xs:enumeration> in the schema.

Best regards,
Dominik Poetz

------------------------------------------------=20
Dominik Poetz
U.S. Department of Commerce=20
National Institute of Standards and Technology=20
100 Bureau Drive=20
227/A157, MS 8394=20
Gaithersburg, MD 20899=20
Phone:  301-975-4645=20
Fax:    301-977-0587=20
Email:  dom...@ni...
------------------------------------------------


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


--=20
------------------------------------------------=20
Dominik Poetz
U.S. Department of Commerce=20
National Institute of Standards and Technology=20
100 Bureau Drive=20
227/A157, MS 8394=20
Gaithersburg, MD 20899=20
Phone:  301-975-4645=20
Fax:    301-977-0587=20
Email:  dom...@ni...
------------------------------------------------