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

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

Hello Dominik,

>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.

I have understood this. What I want to suggest is that you use established =

standard XML tags where
possible. Note that the XML schema data type standard is NOT restricted to =

only XML schema.=20

<quote>
XML Schema: Datatypes is part 2 of the specification of the XML Schema lang=
uage. It defines=20
facilities for defining datatypes to be used in XML Schemas=20
   as well as other XML specifications.=20
The datatype language, which is itself represented in XML 1.0, provides a=20
superset of the capabilities found in XML 1.0 document type definitions=20
(DTDs) for specifying datatypes on elements and attributes.=20
</quote>

The standard XSD types are reused in WSDL for example and IMHO this is a=20
good thing.=20

Can you tell me, what is really the difference between xsd:float and=20
animl:float32 or xsd:double and animl:float64?
I cannot see one, except that the type definition in XSD is probably more=20
exact than the animl one:

<quote>
3.2.5 double
[Definition:]  The double datatype corresponds to IEEE double-precision=20
64-bit floating point type [IEEE 754-1985]. ...  This is the best approxima=
tion of d ([Clinger, WD (1990)], [Gay, DM (1990)]), which is more accurate =
than the mapping required by [IEEE 754-1985]. </quote>.
</quote>


>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.

I have NOT suggested to write a xsd schema for the result xml file. While=20
this had been an earlier proposal from Creon, I have not intented to imply =

this.
I suggested using the same (or a subset actually) of the tags that are=20
also used to define xml schema, instead of
defining new ones, where ever this is useful. From my understanding the=20
<enumeration> tag will be a synonym to <AllowedValue> in this context.=20

>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?

You can include elements from other vocabularies. It is NOT forbidden, in=20
fact it is recommended. And XSD vocabulary is not excluded where it may be =

appropriate.

So instead of writing
<animl:documentation>...</animl:documentation>

you are allowed to write for example:
<xsd:annotation>
        <xsd:documentation>...</xsd:documentation>
=20
<xsd:appinfo><foo:viewer><foo:zoom>2.0</foo:zoom></foo:viewer><xsd:appinfo>
<xsd:annotation>

but here this is only a very minor issue and it is a bad example for this=20
discussion
because documentation is a too generic tag anyway.


>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.

I think that you missunderstood the intention of W3C here. XSD is already=20
used in a number of XML languages outside of schema: WSDL, SOAP, XSL, RDF, =

...
All are official W3C recommendations.

So back I will come back to the example:=20
I would prefer if AnIML takes over the concept used in WSDL here. Provide=20
a type definition section for custom types.

e.g.

<animl:types>
  <schema xmlns=3D"http://www.w3.org/2001/XMLSchema"=20
targetNamespace=3D"http://foo.org">

<xsd:complexType name=3D"SampleStateType" base=3D"xsd:string" minOccurs=3D"=
0"=20
maxOccurs=3D"unbounded">
<xsd:restriction>
<xsd:enumeration>Solid</xsd:enumeration>
...
</animl:types>

<ParameterBlueprint name=3D"SampleState" type=3D"SampleStateType">
<Documentation>Physical=20
> state/preparation of the sample.</Documentation>
</ParameterBlueprint>

or as an alternative, allow a animl:type subelement in place of the=20
animl:type attribute, that contains a in place
XSD type definition.

This reuses the work already done for XSD, and for WSDL in this case, is=20
open and more expressive than we probably ever need.

Actually I think that the AnIML technique definition (template?) XML files =

ARE a indeed a KIND of schema. They define a  syntax and semantics for=20
measurements. So reusing elements from a schema language here would be not
surprising. You (or others) have suggested to extend the technique=20
definitions with new restrictions/extensions that further the XML into a=20
full schema language. I agree that this is necessary, because validation=20
of measurement data is one of the major goals we have with AnIML (esp.=20
regarding CFR 21 Part 11), but I consider reusing someone else's published =

work is better than creating new work for the essentially the same thing.



Regards,

Thomas


---------------------------------------------------------------------------=
------------------
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