Menu
▾
▴
animl-develop — Discussions regarding development
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(1) |
Feb
|
Mar
(9) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(4) |
Sep
(2) |
Oct
|
Nov
(9) |
Dec
(29) |
| 2005 |
Jan
(3) |
Feb
(1) |
Mar
|
Apr
(2) |
May
(1) |
Jun
(2) |
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
| 2006 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
(22) |
May
(7) |
Jun
(3) |
Jul
|
Aug
(3) |
Sep
(5) |
Oct
(1) |
Nov
(2) |
Dec
(4) |
| 2007 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <Mar...@wa...> - 2004-09-01 16:05:52
|
Hi everybody, I have reworked the first AnIML technique documentation based on the suggestions made at the last working meeting. It should become available at http://cvs.sourceforge.net/viewcvs.py/animl/documents/ soon (file date is Sep. 1). Comments and suggestions are welcome. Mit freundlichen Gr=FC=DFen / Best regards Dr. Maren Fiege Product Manager -------------------------------------------------------------- Waters Informatics Europaallee 27, D-50226 Frechen, Germany Tel. +49 2234 9207 - 0 Fax. +49 2234 9207-99 Reply to: mar...@wa... http://www.creonlabcontrol.com http://www.watersinformatics.net -------------------------------------------------------------- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D The information in this email is confidential, and is intended solely for = the addressee(s). Access to this email by anyone else is unauthorized and = therefore prohibited. If you are not the intended recipient you are = notified that disclosing, copying, distributing or taking any action in = reliance on the contents of this information is strictly prohibited and may= = be unlawful. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D |
|
From: <Mar...@wa...> - 2004-08-31 08:23:59
|
Hi everybody, the CVS problem has been solved. The new files are now available. Mit freundlichen Gr=FC=DFen / Best regards Dr. Maren Fiege Product Manager -------------------------------------------------------------- Waters Informatics Europaallee 27, D-50226 Frechen, Germany Tel. +49 2234 9207 - 0 Fax. +49 2234 9207-99 Reply to: mar...@wa... http://www.creonlabcontrol.com http://www.watersinformatics.net -------------------------------------------------------------- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D The information in this email is confidential, and is intended solely for = the addressee(s). Access to this email by anyone else is unauthorized and = therefore prohibited. If you are not the intended recipient you are = notified that disclosing, copying, distributing or taking any action in = reliance on the contents of this information is strictly prohibited and may= = be unlawful. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D |
|
From: <Mar...@wa...> - 2004-08-30 11:56:38
|
Hi everybody, due to a problem with SourceForge's CVS, the new files are not available on the web CVS browser yet (only users of WinCVS can access them). I'm currently trying to solve this together with SourceForge support. Sorry for the delay. Mit freundlichen Gr=FC=DFen / Best regards Dr. Maren Fiege Product Manager -------------------------------------------------------------- Waters Informatics Europaallee 27, D-50226 Frechen, Germany Tel. +49 2234 9207 - 0 Fax. +49 2234 9207-99 Reply to: mar...@wa... http://www.creonlabcontrol.com http://www.watersinformatics.net -------------------------------------------------------------- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D The information in this email is confidential, and is intended solely for = the addressee(s). Access to this email by anyone else is unauthorized and = therefore prohibited. If you are not the intended recipient you are = notified that disclosing, copying, distributing or taking any action in = reliance on the contents of this information is strictly prohibited and may= = be unlawful. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D |
|
From: Burkhard S. <b_...@us...> - 2004-08-28 13:59:08
|
Hi everybody,
I like the idea of includes in a Technique Definition.
A few thoughts and reflections about the Modules system:
- Why don't we treat Definitions and Modules symmetrically?
A Module is a fancy way for including things. It has the same
child nodes as a Definition (except that UsedModule is missing).
This has quite significant effects when using an object mapping tool.
Multiple elements with the same name but different children cause all
kinds of problems here. Additionally, a program that tries to read a
Technique (with modules) must treat things differently depending on
whether it is in a Definition or a Module.
We could think about using only a single branch and - for example - make
the file type choice an attribute to Technique.
<Technique type="{definition|extension|module}" ...>
It would keep software a lot simpler. (Not only the Technique Editors
;-) ). The only downside I see here is that includes can possibly be
recursive; but I guess that's a feature.
- How do we prevent that somebody includes a Module in the wrong way?
It would be good it we could prevent users from inserting Modules at the
wrong place, i.e. put a Page into a ParameterCategory.
- How do we deal with naming conflicts? Do we superimpose like with
Extensions? Sounds reasonable.
Another thought crossed my mind -- how exactly is a Module different
from an Extension? Let's define the semantics:
* An Extension is superimposed at the Root of the Technique
Definition, a Module can be superimposed at many places
below the root.
* An Extension is referenced from an AnIML data file,
a Module is referenced from a Technique Definition
* Both mechanisms formally declare the labels and types of
items in the data file.
Do we really need to differentiate between a Module and an Extension
then? Wouldn't it make sense to unify them and allow Extensions to be
referenced from inside a Technique Definition? This would again reduce
the efforts needed to implement AnIML in applications.
How do you folks think about this?
Best wishes,
Burkhard
PS: Let's keep the discussions on the mailing list so every interested
party can follow and contribute. After all, we are not a private polo
club. ;-)
|
|
From: <Mar...@wa...> - 2004-08-26 20:44:33
|
Hi everybody, =66ollowing up on the discussions at the last E13.15 working meeting, Dominik, Peter and myself have made some changes to the technique schema (now labeled "version 1.1"). The new technique schema, and the technique definition documents adhering to that schema, are now available on the SourceForge CVS server and should also be accessible via web shortly (see http://cvs.sourceforge.net/viewcvs.py/animl/). Please share your comments on this mailing list. Mit freundlichen Gr=FC=DFen / Best regards Dr. Maren Fiege Product Manager -------------------------------------------------------------- Waters Informatics Europaallee 27, D-50226 Frechen, Germany Tel. +49 2234 9207 - 0 Fax. +49 2234 9207-99 Reply to: mar...@wa... http://www.creonlabcontrol.com http://www.watersinformatics.net -------------------------------------------------------------- =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D The information in this email is confidential, and is intended solely for = the addressee(s). Access to this email by anyone else is unauthorized and = therefore prohibited. If you are not the intended recipient you are = notified that disclosing, copying, distributing or taking any action in = reliance on the contents of this information is strictly prohibited and may= = be unlawful. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D The information in this email is confidential, and is intended solely for = the addressee(s). Access to this email by anyone else is unauthorized and = therefore prohibited. If you are not the intended recipient you are = notified that disclosing, copying, distributing or taking any action in = reliance on the contents of this information is strictly prohibited and may= = be unlawful. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D The information in this email is confidential, and is intended solely for = the addressee(s). Access to this email by anyone else is unauthorized and = therefore prohibited. If you are not the intended recipient you are = notified that disclosing, copying, distributing or taking any action in = reliance on the contents of this information is strictly prohibited and may= = be unlawful. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D |
|
From: Dominik P. <dom...@ni...> - 2004-07-21 18:11:12
|
Hi folks, I want to inform you that I will go back to Germany tomorrow. My NIST e-mail address will expaire by the end of this month, but I will not be able to check them. Please send future e-mails to: ma...@do... Best regards, Dominik Poetz ------------------------------------------------ Dominik Poetz U.S. Department of Commerce National Institute of Standards and Technology 100 Bureau Drive 227/A157, MS 8394 Gaithersburg, MD 20899 Phone: 301-975-4645 Fax: 301-977-0587 ------------------------------------------------ |
|
From: <Mar...@cr...> - 2004-03-15 12:33:26
|
Hi Dominik, as Gary surely told you already, we are supposed to freeze the code on Friday, hopefully having solved this issue by then. > the discussion that I started was supposed to be on the technique lay= er. Right. My mistake. > The "allowed values" won't influence the Part11 compliance issue beca= use they do not > directly restrict the AnIML file. You just use them for validation > issues. This is exactly the point: You end up having *invalid* AnIML data even though everything aside from the data range is correct! This will most likely be very unfortunate for people working in a validated environmen= t. > i.e. that the AnIML file is not > valid against that definition because the measured value is out of > range. And that is what we would want, beacause the developer of the > technique said that the results must be in a particular range, otherw= ise > the file is incorrect. This is something I definitely would not want. It doesn't even give us = any kind of benefit. Let's use NMR as an example: The chemical shift is highly dependent on = the nucleus. 1H NMR spectra are usually (!) between about -2 and +15 ppm. 1= 3C NMR is between -20 and +250 ppm. Some more "exotic" NMR techniques can easily have ranges in the negative hundreds. Which range would you allo= w for the data? To catch them all, you would need something from -500 to = +500 ppm, which is no real restriction at all because an 1H NMR from 130 to = 400 ppm would be perfectly valid although you would most probably never encounter it in reality. The other possibility would be creating multiple technique definitions = (or one very complex one) for NMR, which cannot be our goal either because = it would mean creating a lot of redundant information. The only place I could imagine such a restriction in is a user extensio= n, but most probably, no one would use this. So we might as well leave it = out. Maybe someone else on this list can contribute something here. It's jus= t you and me discussing this issue again :-) > Regarding the other mail, with the idea to allow ranges of "allowed > values," we still have the ability to set just one value (e.g., strin= g > or number), or better yet let's say any simple type. We can do this b= y > just assigning a value to the minimum tag while leaving the maximum t= ag > free, or write the same value in both tags. So this is just a questio= n > of modelling. OK, let's incorporate allowed ranges for parameters. Can you add that t= o the schema I last sent you and send me the new schema? Maren. Dr. Maren Fiege Product Manager -----------------------------------------------------------------------= ---------------------- 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 http://www.creonlabcontrol.com For up-to-date information subscribe to our free newsletter at http://www.creonlabcontrol.com/news/news_archive.htm -----------------------------------------------------------------------= ---------------------- = =20 Dominik Poetz = =20 <dominik.poetz@ To: Maren.Fiege@creonlabco= ntrol.com =20 nist.gov> cc: Stuart Chalk <schalk@u= nf.edu>, AnIML Mailing List =20 <ani...@li...= forge.net>, AnIML Mailing List =20 07.03.2004 <ani...@li...= orge.net>, =20 04:23 ani...@li...= urceforge.net =20 Subject: Re: [Animl-develo= p] Allowed Values in AnIML =20 = =20 Hi Maren, the discussion that I started was supposed to be on the technique layer= . This is the only place where we can set "Allowed Values." The "allowed= values" won't influence the Part11 compliance issue because they do not= directly restrict the AnIML file. You just use them for validation issues. For example: Let's say a technique developer creates a specific parameter with an allowed value range in his technique definition. Sombody then makes a measurement where that parameter value is out of range, and after that he validates his resulting AnIML file against that technique definition= from that particular technique developer. What would happen is that the= validator will indicate an exception, i.e. that the AnIML file is not valid against that definition because the measured value is out of range. And that is what we would want, beacause the developer of the technique said that the results must be in a particular range, otherwis= e the file is incorrect. Regardless if the data is out of range or not, the original AnIML contains only the raw, measured values without further manipulation, which should be fine for Part 11. The same can be= true for vectors if we decide to add "Allowd Values" to the vectors too= . Regarding the other mail, with the idea to allow ranges of "allowed values," we still have the ability to set just one value (e.g., string or number), or better yet let's say any simple type. We can do this by just assigning a value to the minimum tag while leaving the maximum tag= free, or write the same value in both tags. So this is just a question of modelling. -- Dominik Mar...@cr... wrote: >Dear Dr. Chalk, > > > >>Both MP and BP (shouldn't they be MeltingPoint and BoilingPoint) are = in >>most cases ranges of numbers. >> >> >The ability to store this is a matter of the technique definition, not= of >the Core schema (to which Dominik was referring). >As I am currently writing prototype technique definitions, I will glad= ly >incorporate this. Thank you for reminding me! > > > >>As a general note I am stating to work on implementing animl in my la= b >> >> >and > > >>I have many other questions. >> >> >Forgive my curiosity: What do you mean by "implementing"? > > > >>Would it be possible to set up CVS for animl development? >> >> >This is generally possible on SourceForge, and used to work, but as fa= r as >I know there has been some kind of problem. Some people started to try= and >make it work again after this was requested at the last working meetin= g.. >Maybe someone can update us on the current status. > > > >>When I say bugs I mean XSD issues that are either too limiting or are= not >>well enough defined. Just a thought. FYI: I can help with both.... = ;) >> >> >The animl-develop mailing list is exactly the place to discuss this. S= o >let's hear your bug reports! > >Best regards, > >Dr. Maren Fiege >Product Manager > > -----------------------------------------------------------------------= ---------------------- > >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 > >http://www.creonlabcontrol.com > >For up-to-date information subscribe to our free newsletter at >http://www.creonlabcontrol.com/news/news_archive.htm > -----------------------------------------------------------------------= ---------------------- > > > > Stuart Chalk <sc...@un...> > Sent by: To: Domin= ik Poetz <dom...@ni...> > ani...@li... cc: AnIML= Mailing List > eforge.net <ani...@li...>, AnIML Mailing > List <ani...@li...> > Subject: = Re: [Animl-develop] Allowed Values in AnIML > 05.03.2004 10:47 > > > > > > >The same is true in the parameter data for a SampleSet > >Both MP and BP (shouldn't they be MeltingPoint and BoilingPoint) are i= n >most cases ranges of numbers. > >As a general note I am stating to work on implementing animl in my lab= and >I have many other questions. Would it be possible to set up CVS for a= niml >development? Then people can report bugs and have those bugs worked o= n.. >When I say bugs I mean XSD issues that are either too limiting or are = not >well enough defined. Just a thought. FYI: I can help with both.... ;= ) > >Stuart Chalk, Ph.D. **NEW** Phone:904-620-= 1938 >Associate Professor of Chemistry Fax:904-620-= 3885 >Department of Chemistry and Physics "The Flow Analysis Datab= ase" >University of North Florida http://www.fia.unf.= edu/ >4567 St. Johns Bluff Road S. "The Analytical Sciences Digital Libr= ary" >Jacksonville FL 32224 USA http://www.asdlib.= org/ > >On Thu, 4 Mar 2004, Dominik Poetz wrote: > > > >>Hi everybody, >> >> >>I hope everyone is doing well. >> >>At the last AnIML Working Group meeting, we discussed wanting to allo= w >>multiple, single "allowed values" for parameter values in the techniq= ue >> >> >layer. > > >>Instead of multiple, single "AllowedValue" values, we might do better= to >> >> >allow > > >>ranges of "AllowedValue" values. For example, with temperature it wo= uld >> >> >be > > >>better to allow this "AllowedValue" to range between a minimum value = and >> >> >a > > >>maximum value. To specify a single value we would have to put the va= lue >> >> >in > > >>both, Min and Max fields or maybe the Max field would be empty. But t= his >> >> >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 th= eir >> >> >vendor > > >>extensions if they want. >> >>On another subtopic, shouldn't we add a flag (attribute) to >> >> >"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 desig= ning >>techniques. To promote better understanding, we might choose to renam= e >> >> >the > > >>"AllowedValue" to maybe "RestrictedRange" or "QualifiedRange." >> >>In addition, do we need a similar notation for vectors? >> >>It would be nice to get some more ideas about this. >> >>Hope to hear from you, >> >>Dominik >> >>------------------------------------------------ >>Dominik Poetz >>U.S. Department of Commerce >>National Institute of Standards and Technology 100 Bureau Drive >>227/A157, MS 8394 >>Gaithersburg, MD 20899 >>Phone: 301-975-4645 >>Fax: 301-977-0587 >>Email: dom...@ni... >>------------------------------------------------ >> >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by: IBM Linux Tutorials >>Free Linux tutorial presented by Daniel Robbins, President and CEO of= >>GenToo technologies. Learn everything from fundamentals to system >>administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3D= click >>_______________________________________________ >>Animl-develop mailing list >>Ani...@li... >>https://lists.sourceforge.net/lists/listinfo/animl-develop >> >> >> > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3D= click >_______________________________________________ >Animl-develop mailing list >Ani...@li... >https://lists.sourceforge.net/lists/listinfo/animl-develop > > > > > > > > = |
|
From: <Tho...@cr...> - 2004-03-09 10:56:38
|
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
|
|
From: Dominik P. <dom...@ni...> - 2004-03-08 21:07:14
|
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... ------------------------------------------------ |
|
From: <Tho...@cr...> - 2004-03-08 09:27:32
|
>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
|
|
From: Dominik P. <dom...@ni...> - 2004-03-07 02:31:16
|
Hi Maren, the discussion that I started was supposed to be on the technique layer.=20 This is the only place where we can set "Allowed Values." The "allowed=20 values" won't influence the Part11 compliance issue because they do not=20 directly restrict the AnIML file. You just use them for validation=20 issues. For example: Let's say a technique developer creates a specific parameter with an=20 allowed value range in his technique definition. Sombody then makes a=20 measurement where that parameter value is out of range, and after that=20 he validates his resulting AnIML file against that technique definition=20 from that particular technique developer. What would happen is that the=20 validator will indicate an exception, i.e. that the AnIML file is not=20 valid against that definition because the measured value is out of=20 range. And that is what we would want, beacause the developer of the=20 technique said that the results must be in a particular range, otherwise=20 the file is incorrect. Regardless if the data is out of range or not,=20 the original AnIML contains only the raw, measured values without=20 further manipulation, which should be fine for Part 11. The same can be=20 true for vectors if we decide to add "Allowd Values" to the vectors too. Regarding the other mail, with the idea to allow ranges of "allowed=20 values," we still have the ability to set just one value (e.g., string=20 or number), or better yet let's say any simple type. We can do this by=20 just assigning a value to the minimum tag while leaving the maximum tag=20 free, or write the same value in both tags. So this is just a question=20 of modelling. -- Dominik Mar...@cr... wrote: >Dear Dr. Chalk, > > =20 > >>Both MP and BP (shouldn't they be MeltingPoint and BoilingPoint) are in >>most cases ranges of numbers. >> =20 >> >The ability to store this is a matter of the technique definition, not o= f >the Core schema (to which Dominik was referring). >As I am currently writing prototype technique definitions, I will gladly >incorporate this. Thank you for reminding me! > > =20 > >>As a general note I am stating to work on implementing animl in my lab >> =20 >> >and > =20 > >>I have many other questions. >> =20 >> >Forgive my curiosity: What do you mean by "implementing"? > > =20 > >>Would it be possible to set up CVS for animl development? >> =20 >> >This is generally possible on SourceForge, and used to work, but as far = as >I know there has been some kind of problem. Some people started to try a= nd >make it work again after this was requested at the last working meeting.. >Maybe someone can update us on the current status. > > =20 > >>When I say bugs I mean XSD issues that are either too limiting or are n= ot >>well enough defined. Just a thought. FYI: I can help with both.... ;) >> =20 >> >The animl-develop mailing list is exactly the place to discuss this. So >let's hear your bug reports! > >Best regards, > >Dr. Maren Fiege >Product Manager > >------------------------------------------------------------------------= --------------------- > >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 > >http://www.creonlabcontrol.com > >For up-to-date information subscribe to our free newsletter at >http://www.creonlabcontrol.com/news/news_archive.htm >------------------------------------------------------------------------= --------------------- > > > = =20 > Stuart Chalk <sc...@un...> = =20 > Sent by: To: Dominik= Poetz <dom...@ni...> =20 > ani...@li... cc: AnIML M= ailing List =20 > eforge.net <animl-announ= ce...@li...>, AnIML Mailing =20 > List <animl-d= ev...@li...> =20 > Subject: Re= : [Animl-develop] Allowed Values in AnIML =20 > 05.03.2004 10:47 = =20 > = =20 > = =20 > > > > >The same is true in the parameter data for a SampleSet > >Both MP and BP (shouldn't they be MeltingPoint and BoilingPoint) are in >most cases ranges of numbers. > >As a general note I am stating to work on implementing animl in my lab a= nd >I have many other questions. Would it be possible to set up CVS for ani= ml >development? Then people can report bugs and have those bugs worked on.. >When I say bugs I mean XSD issues that are either too limiting or are no= t >well enough defined. Just a thought. FYI: I can help with both.... ;) > >Stuart Chalk, Ph.D. **NEW** Phone:904-620-19= 38 >Associate Professor of Chemistry Fax:904-620-38= 85 >Department of Chemistry and Physics "The Flow Analysis Databas= e" >University of North Florida http://www.fia.unf.ed= u/ >4567 St. Johns Bluff Road S. "The Analytical Sciences Digital Librar= y" >Jacksonville FL 32224 USA http://www.asdlib.or= g/ > >On Thu, 4 Mar 2004, Dominik Poetz wrote: > > =20 > >>Hi everybody, >> >> >>I hope everyone is doing well. >> >>At the last AnIML Working Group meeting, we discussed wanting to allow >>multiple, single "allowed values" for parameter values in the technique >> =20 >> >layer. > =20 > >>Instead of multiple, single "AllowedValue" values, we might do better t= o >> =20 >> >allow > =20 > >>ranges of "AllowedValue" values. For example, with temperature it woul= d >> =20 >> >be > =20 > >>better to allow this "AllowedValue" to range between a minimum value an= d >> =20 >> >a > =20 > >>maximum value. To specify a single value we would have to put the valu= e >> =20 >> >in > =20 > >>both, Min and Max fields or maybe the Max field would be empty. But thi= s >> =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 thei= r >> =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 designi= ng >>techniques. To promote better understanding, we might choose to rename >> =20 >> >the > =20 > >>"AllowedValue" to maybe "RestrictedRange" or "QualifiedRange." >> >>In addition, do we need a similar notation for vectors? >> >>It would be nice to get some more ideas about this. >> >>Hope to hear from you, >> >>Dominik >> >>------------------------------------------------ >>Dominik Poetz >>U.S. Department of Commerce >>National Institute of Standards and Technology 100 Bureau Drive >>227/A157, MS 8394 >>Gaithersburg, MD 20899 >>Phone: 301-975-4645 >>Fax: 301-977-0587 >>Email: dom...@ni... >>------------------------------------------------ >> >> >> >>------------------------------------------------------- >>This SF.Net email is sponsored by: IBM Linux Tutorials >>Free Linux tutorial presented by Daniel Robbins, President and CEO of >>GenToo technologies. Learn everything from fundamentals to system >>administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dc= lick >>_______________________________________________ >>Animl-develop mailing list >>Ani...@li... >>https://lists.sourceforge.net/lists/listinfo/animl-develop >> >> =20 >> > > >------------------------------------------------------- >This SF.Net email is sponsored by: IBM Linux Tutorials >Free Linux tutorial presented by Daniel Robbins, President and CEO of >GenToo technologies. Learn everything from fundamentals to system >administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcl= ick >_______________________________________________ >Animl-develop mailing list >Ani...@li... >https://lists.sourceforge.net/lists/listinfo/animl-develop > > > > > > > =20 > |
|
From: <Mar...@cr...> - 2004-03-07 00:50:24
|
Dear Dr. Chalk, > Both MP and BP (shouldn't they be MeltingPoint and BoilingPoint) are = in > most cases ranges of numbers. The ability to store this is a matter of the technique definition, not = of the Core schema (to which Dominik was referring). As I am currently writing prototype technique definitions, I will gladl= y incorporate this. Thank you for reminding me! > As a general note I am stating to work on implementing animl in my la= b and > I have many other questions. Forgive my curiosity: What do you mean by "implementing"? > Would it be possible to set up CVS for animl development? This is generally possible on SourceForge, and used to work, but as far= as I know there has been some kind of problem. Some people started to try = and make it work again after this was requested at the last working meeting= . Maybe someone can update us on the current status. > When I say bugs I mean XSD issues that are either too limiting or are= not > well enough defined. Just a thought. FYI: I can help with both.... = ;) The animl-develop mailing list is exactly the place to discuss this. So= let's hear your bug reports! Best regards, Dr. Maren Fiege Product Manager -----------------------------------------------------------------------= ---------------------- 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 http://www.creonlabcontrol.com For up-to-date information subscribe to our free newsletter at http://www.creonlabcontrol.com/news/news_archive.htm -----------------------------------------------------------------------= ---------------------- = =20 Stuart Chalk <sc...@un...> = =20 Sent by: To: Domini= k Poetz <dom...@ni...> =20 ani...@li... cc: AnIML = Mailing List =20 eforge.net <animl-annou= nc...@li...>, AnIML Mailing =20 List <animl-= de...@li...> =20 Subject: R= e: [Animl-develop] Allowed Values in AnIML =20 05.03.2004 10:47 = =20 = =20 = =20 The same is true in the parameter data for a SampleSet Both MP and BP (shouldn't they be MeltingPoint and BoilingPoint) are in= most cases ranges of numbers. As a general note I am stating to work on implementing animl in my lab = and I have many other questions. Would it be possible to set up CVS for an= iml development? Then people can report bugs and have those bugs worked on= . When I say bugs I mean XSD issues that are either too limiting or are n= ot well enough defined. Just a thought. FYI: I can help with both.... ;)= Stuart Chalk, Ph.D. **NEW** Phone:904-620-1= 938 Associate Professor of Chemistry Fax:904-620-3= 885 Department of Chemistry and Physics "The Flow Analysis Databa= se" University of North Florida http://www.fia.unf.e= du/ 4567 St. Johns Bluff Road S. "The Analytical Sciences Digital Libra= ry" Jacksonville FL 32224 USA http://www.asdlib.o= rg/ On Thu, 4 Mar 2004, Dominik Poetz wrote: > Hi everybody, > > > I hope everyone is doing well. > > At the last AnIML Working Group meeting, we discussed wanting to allo= w > multiple, single "allowed values" for parameter values in the techniq= ue layer. > > Instead of multiple, single "AllowedValue" values, we might do better= to allow > ranges of "AllowedValue" values. For example, with temperature it wo= uld be > better to allow this "AllowedValue" to range between a minimum value = and a > maximum value. To specify a single value we would have to put the va= lue in > both, Min and Max fields or maybe the Max field would be empty. But t= his 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 th= eir vendor > extensions if they want. > > On another subtopic, shouldn't we add a flag (attribute) to "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 desig= ning > techniques. To promote better understanding, we might choose to renam= e the > "AllowedValue" to maybe "RestrictedRange" or "QualifiedRange." > > In addition, do we need a similar notation for vectors? > > It would be nice to get some more ideas about this. > > Hope to hear from you, > > Dominik > > ------------------------------------------------ > Dominik Poetz > U.S. Department of Commerce > National Institute of Standards and Technology 100 Bureau Drive > 227/A157, MS 8394 > Gaithersburg, MD 20899 > Phone: 301-975-4645 > Fax: 301-977-0587 > Email: dom...@ni... > ------------------------------------------------ > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of= > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3D= click > _______________________________________________ > Animl-develop mailing list > Ani...@li... > https://lists.sourceforge.net/lists/listinfo/animl-develop > ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dc= lick _______________________________________________ Animl-develop mailing list Ani...@li... https://lists.sourceforge.net/lists/listinfo/animl-develop = |
|
From: <Mar...@cr...> - 2004-03-07 00:39:35
|
Hi Dominik, > Instead of multiple, single "AllowedValue" values, we might do better= to allow > ranges of "AllowedValue" values. For example, with temperature it wo= uld be > better to allow this "AllowedValue" to range between a minimum value = and a > maximum value. This sounds like a good idea to me. However, we have to keep the possibility to specify multiple single values in case we have a string value we want to restrict. > On another subtopic, shouldn't we add a flag (attribute) to "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 desig= ning > techniques. To promote better understanding, we might choose to renam= e the > "AllowedValue" to maybe "RestrictedRange" or "QualifiedRange." > In addition, do we need a similar notation for vectors? This would be OK for Parameters. We shouldn't restrict the measured dat= a, however, unless we want to lose 21VFR11 compliance. Best regards, Dr. Maren Fiege Product Manager -----------------------------------------------------------------------= ---------------------- 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 http://www.creonlabcontrol.com For up-to-date information subscribe to our free newsletter at http://www.creonlabcontrol.com/news/news_archive.htm -----------------------------------------------------------------------= ----------------------= |
|
From: Stuart C. <sc...@un...> - 2004-03-05 16:54:51
|
The same is true in the parameter data for a SampleSet Both MP and BP (shouldn't they be MeltingPoint and BoilingPoint) are in most cases ranges of numbers. As a general note I am stating to work on implementing animl in my lab and I have many other questions. Would it be possible to set up CVS for animl development? Then people can report bugs and have those bugs worked on. When I say bugs I mean XSD issues that are either too limiting or are not well enough defined. Just a thought. FYI: I can help with both.... ;) Stuart Chalk, Ph.D. **NEW** Phone:904-620-1938 Associate Professor of Chemistry Fax:904-620-3885 Department of Chemistry and Physics "The Flow Analysis Database" University of North Florida http://www.fia.unf.edu/ 4567 St. Johns Bluff Road S. "The Analytical Sciences Digital Library" Jacksonville FL 32224 USA http://www.asdlib.org/ On Thu, 4 Mar 2004, Dominik Poetz wrote: > Hi everybody, > > > I hope everyone is doing well. > > At the last AnIML Working Group meeting, we discussed wanting to allow > multiple, single "allowed values" for parameter values in the technique layer. > > Instead of multiple, single "AllowedValue" values, we might do better to allow > ranges of "AllowedValue" values. For example, with temperature it would be > better to allow this "AllowedValue" to range between a minimum value and a > maximum value. To specify a single value we would have to put the value in > both, Min and Max fields or maybe the Max field would be empty. But 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 their vendor > extensions if they want. > > On another subtopic, shouldn't we add a flag (attribute) to "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 designing > techniques. To promote better understanding, we might choose to rename the > "AllowedValue" to maybe "RestrictedRange" or "QualifiedRange." > > In addition, do we need a similar notation for vectors? > > It would be nice to get some more ideas about this. > > Hope to hear from you, > > Dominik > > ------------------------------------------------ > Dominik Poetz > U.S. Department of Commerce > National Institute of Standards and Technology 100 Bureau Drive > 227/A157, MS 8394 > Gaithersburg, MD 20899 > Phone: 301-975-4645 > Fax: 301-977-0587 > Email: dom...@ni... > ------------------------------------------------ > > > > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click > _______________________________________________ > Animl-develop mailing list > Ani...@li... > https://lists.sourceforge.net/lists/listinfo/animl-develop > |
|
From: Dominik P. <dom...@ni...> - 2004-03-04 22:29:48
|
Hi everybody, I hope everyone is doing well. At the last AnIML Working Group meeting, we discussed wanting to allow multiple, single "allowed values" for parameter values in the technique layer. Instead of multiple, single "AllowedValue" values, we might do better to allow ranges of "AllowedValue" values. For example, with temperature it would be better to allow this "AllowedValue" to range between a minimum value and a maximum value. To specify a single value we would have to put the value in both, Min and Max fields or maybe the Max field would be empty. But 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 their vendor extensions if they want. On another subtopic, shouldn't we add a flag (attribute) to "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 designing techniques. To promote better understanding, we might choose to rename the "AllowedValue" to maybe "RestrictedRange" or "QualifiedRange." In addition, do we need a similar notation for vectors? It would be nice to get some more ideas about this. Hope to hear from you, Dominik ------------------------------------------------ Dominik Poetz U.S. Department of Commerce National Institute of Standards and Technology 100 Bureau Drive 227/A157, MS 8394 Gaithersburg, MD 20899 Phone: 301-975-4645 Fax: 301-977-0587 Email: dom...@ni... ------------------------------------------------ |
|
From: Burkhard S. <bur...@ni...> - 2004-01-31 06:07:32
|
... |
|
From: SourceForge.net <no...@so...> - 2003-09-26 13:25:54
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2210184 By: dmartinsen I agree with your argument. However, I would support requiring an endian attribute, but limiting its allowed value to "little". This accomplishes 2 things. First, it removes any ambiguity over how the data were stored. Second, by refusing to validate other endian values, it forces the person writing the software to use the proper format (or at least to make them aware that they are violating the standard and producing corrupt files when saying data are little-endian but storing big-endian). Dave Martinsen ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=262127 |
|
From: SourceForge.net <no...@so...> - 2003-09-22 22:10:51
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2204188 By: choconutdancer I'd like to recommend that we not have a endian flag. Doing so will require ALL software that wants to read the file to be able to read BOTH types of endian data. Every reader software is guaranteed to have to write a conversion routine for the opposite endian. Specifying a single endian will mean that a software package will only have to support reading one endian format. Little endian (Intel) is probably the most common. Even if you have a machine cpu with the opposite endian you will still only need to support a single format and not two. (An opposite endian machine would still have to support a conversion whether there was an endian flag or not). But at least you're not forcing EVERY piece of software that wants to read the data to support BOTH endian types. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=262127 |
|
From: SourceForge.net <no...@so...> - 2003-09-22 21:31:59
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2204137 By: choconutdancer Accuracy problems of representing base 10 numbers in base 2 binary only applies to fractional values. A 64 bit float has 52 bits of mantissa. It can represent all 32 bits integers without ANY loss in precision. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=262127 |
|
From: SourceForge.net <no...@so...> - 2003-09-22 21:31:18
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2204134 By: jhduck First I apologize for my absence at the last few meetings; with that in mind my comments below are possibly out of context from what was actually proposed. I just had a chance to review the proposed schemas from Waters\Creon-LabControl and one thing struck me - there is significant separate of the relevant information on the analysis performed (i.e. the scan record in the MS element of the Technique schema) and the measured data (i.e. the SVector or TVector in the Core schema). I cannot see how these bits of information which are fundamentally related will be tied together in the layered schema approach proposed. In thinking about it a bit, shouldn't the "lower level" schemas (i.e. Core, Sample) expose their element definitions as XSD ComplexTypes that can be use to define subelement types in the higher order schemas? Otherwise, the data links between relevant portions of the data set will be obscured by the XML hierarchy at best; at worst the links might be completely impossible to make. Again, I may be missing something since I was not able to attend the meetings where this work was presented. - - James Duckworth, Thermo Electron Corp. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/unmonitor.php?forum_id=262127 |
|
From: SourceForge.net <no...@so...> - 2003-05-07 13:16:18
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2005699 By: trgilmore it is diffucult to view numbers as there is a conversion from the numerical representation (ieee) vs the ASCII that you can see. That is my point. The representation should be the SAME as the storage, then the person creating the record can control what is there: what you see is what you get. To try this look at the internal representation of the number 50. It is stored as a number other that 50 times a binary exponent of 32 or 64. The number can be very close to a 50, but it cannot be 50. If you want a 50, the number should be represented as a decimal witha power of 10 exponent, but this is not the standard computer notation. ORACLE in the database stores number as character with up to 38 characters in a decimal system, so there is no tranformation of the number. Characters do not necessarily take more room for storage as 8 characters may not use more space than a 64bit ieee number. There should certainly be a descriptor in the standard to identify the shape of a data block! ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/monitor.php?forum_id=262127 |
|
From: SourceForge.net <no...@so...> - 2003-05-05 14:40:23
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2001746 By: beanmf I am not at all expert on computer representation of numbers but I tested Tom's assertion about the number 10 in C#.Net double test = 10; double newTest = test; the value held in newTest was 10.0 which has the same value as 10 but with a different precision. In our discussions about precision in the past, we differentiated between measurement precision and representation precision. If we acquire data with an ADC, then realistic measurement precision may be hard to assess from a graph without further information; thus measurement precision was thought to lie outside the domain of mere data representation. I personally cannot decipher why we would care if a number was represented as 10.0 or 10 as long as the measurement precision was accessible somewhere. Numbers represented as strings may be difficult to array in many languages, such as C and its derivatives, as the size of the string must be known at compile time, and all number strings must be the same size to be held in an array. That is of course one of the chief reasons (other than space) for adopting binary rather than character representations. ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/monitor.php?forum_id=262127 |
|
From: SourceForge.net <no...@so...> - 2003-05-05 13:06:33
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=2001568 By: rkjulian When representing numbers of characters doesn't this pose an issue with rounding errors? This is an issue in Java I/O where you have to take care when printing numbers to be read back in such that the bit pattern will be the same when the string is converted back into a float. There are really two issues here: 1. the size of the output (strings are bigger) 2. problems with rounding Any thoughts? Randy ______________________________________________________________________ You are receiving this email because you elected to monitor this forum. To stop monitoring this forum, login to SourceForge.net and visit: https://sourceforge.net/forum/monitor.php?forum_id=262127 |
3 messages has been excluded from this view by a project administrator.
