Currently a series can have AllTypeNameList (parameters as well) and while it is most often suitable to specify the type it is sometimes not generic enough, e.g. one can have a table of key/value pairs and each value might be a different type.

The XML can easily express this using a mixture of <S>, <I>, ... in a table or parameter but there is now way to express this in the technique definition.

I therefore like to suggest to specify an "Any" Type that can be used for whatever type is desired, this is similar to "numeric" where it allows any integer or floating point value (even though the spec is not clear for tables if a mixed value mode is acceptable).

Currently AnIML specify three kind of series types

beside the AutoIncrementedValueSet they are all quite exhaustive in the result in terms of storage space and quite limited, e.g. the EncodedValueSet requires a specific encoding (while it is not completely specified how data is encoded), and IndividualValueSet always requires additional tags, also the XSD can not be used to effectively constrain the used values to the correct data type.

Because of this I'd like to propose two new types of value sets:

1. NumbericValueSet what is of type xsd:list holding xsd:numeric types, this is much more space efficient (e.g. only a plain list of space delimited numbers) but still can hold different datatypes, so for a series of INT one might simply specify that all values have to be interpreted as such instead of wrapping the actual value.
2. BlobValueSet what has an attribute encoding that specifies the data stored in it what might be a common type specified in the AnIML specification (e.g. gzip, RLE, delta-compressed-double, ...) or even custom types, which can hold either an element <data> (with base64 encoded data) or <reference> (that holds a reference e.g. to a file next to the animl, database id or similar) to offload the real data bytes and allows the xs:any content type so it can be enhanced with any required custom data.

I think the file extension as discussed in #4 (comment) should be specified as thirdparty tools use the generic *.xml ending which will cause problems. See https://sciencesolutions.wiley.com/wp-content/uploads/2021/08/210421-Wiley_KnowItAll_Software_File_Format_Datasheet.pdf

https://www.animl.org currently only times out but do not deliver any content.

If hosting an own website is currently not desired, it would be good if it redirects to
https://github.com/AnIML

and an organization readme is created so users can contribute data there more easily:
https://docs.github.com/en/organizations/collaborating-with-groups-in-organizations/customizing-your-organizations-profile#organization-profile-readmes

astm.core.UnitType and astm.core.SIUnitType but also astm.technique.UnitType and astm.technique.SIUnitType exist, which causes problems when implementing this in strictly type safe languages such as Java from automatically generated code using xjc. It also looks like the definitions are completely redundant.

Hi,
it would be great if this repo (actually, both AniML repos) carried some license information.
Which license to choose is of course up to you.
Yours,
Steffen

For adaptors and implementers it is very useful to have more examples
esp. HPLC, GC, microtiterplates, UV-vis, ...

Please add much more examples !
At least 3-5 for each major evolved technique.

Thanks a lot.

Let's see if we can use xsd2code to generate code from the AnIML schemas.

Link: http://xsd2code.codeplex.com/

Ensure that the core and technique schema works in the current Microsoft XML tools.