Re: [Psidev-ms-dev] dataXML 0.9 ready for first feedbacks

[Mike C. <tu...@gm...>]

On 2/6/07, Pierre-Alain Binz <pie...@is...> wrote:
>  dataXML (as being the merge between mzData and mzXML, and becoming the PSI
> MS data standard replacing mzData) is ready for a first feedback from you,
> implementers and PSI MS active members. We target to finalise version 1.0
> right after the next PSI Spring Workshop (see below)

Looking on this page, the only normative material I'm seeing are the
two XML schema.  Is there other material that I'm missing?  I would
have expected to see detailed normative prose describing the meaning
and proper usage of the various elements.  Without this, implementers
will probably use this schema in incompatible ways, leading to future
headaches.

Here are a couple of examples of what seems to be missing.  I think I
know that the X axis for spectrum data represents M/Z values, where M
is mass in amu's and Z is the integer charge.  This ought to be
specified explicitly.

As a more detailed example, I think I know that spectrum data is
represented as the base64-encoded form of IEEE float values.  (This
also needs to be specified.)   IEEE floats can take on several special
values like "positive infinity" and error values.  Is it legal to
place these values in a dataXML file?  Whether or not this is so, what
is a receiver expected to do if it encounters such values?

As an example of the kind of normative prose I'm thinking of, here is
a link to a working copy of an ANSI C standard

    http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf

(Obviously, the dataXML prose would be much shorter.)

Another nice thing that the ANSI C committee produces is a rationale
document, which explains the reasoning behind many of the major
decisions taken, correlated to the specification.  It would be nice to
have an mzData rationale document as well, to explain the thinking
behind its design decisions (e.g., base64/binary representation of
floats).

    http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf

Regards,
Mike Coleman