RE: Common schema units of measure
While enforcing a set of standard units through schema validation is
definitely beneficial, I think it is equally important to allow arbitrary,
non-standard units. In many cases TestResults documents will be generated
from existing TPSs that may use such units. For example, ATLAS allows users
to extend signal types (nouns) with attributes (modifiers) that have
arbitrary units. Thus, somebody may have defined a unit of "Pulses" for a
pulse count, where the correct unit would have been "non-dimensional". For
traceability to the original TPS, recording the _original_ unit (even if
incorrect) is necessary.
Deviation from the set of standard units can be supported in a "controlled"
manner, for example:
- by adding a "customUnit" attribute to Datum and indicating in the text of
the spec that "unit" and "customUnit" are alternative; possibly rename
"unit" to "standardUnit"
- by creating a complex type for Unit, with a choice of StandardUnit (of
type c:Unit) and CustomUnit (c:NonBlankString)
Naturally, one could use data type extension to support arbitrary units.
However, the use case seems frequent enough to justify some level of support
in the Common schema.
Ion
--
Ion Neag
TYX Corporation
> -----Original Message-----
> From: owner-stds-scc20-atml@ieee.org [mailto:owner-stds-scc20-
> atml@ieee.org] On Behalf Of Chris.Gorringe@RACALINSTRUMENTSGROUP.CO.UK
> Sent: Thursday, December 15, 2005 11:53 AM
> To: stds-scc20-atml@listserv.ieee.org
> Cc: Stephen.Osella@ni.com
> Subject: RE: [Maybe spam] Common schema units of measure - Use Option 2
> plus
>
> No - but I think we should include it
>
> How do we think its spelt ppm (PpM) (ppM) you can only chose one
> ppm belongs to the Ratio (Dimensionless unit) such that 1000 ppm is 0.001
> which is 0.1%
>
> However with these types of units there is ambiguity in what kppm means is
> it k(ppm) or (kp)pm, thats why its generally not defined as a unit term
>
> Note IEEE SI10 says do not use ppm, ppb or ppt (parts per Billion) or
> (parts per Trillion) because Billion and Trillion have different values in
> different countries!!
> However since 1 million is universially recognised as 1e6 I can not a
> problem with ppm apart from the prefix issue
>
> Chris
> > -----Original Message-----
> > From: Stephen.Osella@ni.com [SMTP:Stephen.Osella@ni.com]
> > Sent: 15 December 2005 14:31
> > To: stds-scc20-atml@listserv.ieee.org
> > Cc: Gorringe, Chris
> > Subject: RE: [Maybe spam] Common schema units of measure - Use Option
2
> plus
> >
> > Does the schema allow a unit for "Parts Per Million" i.e., PPM ?
> >
> > Stephen Osella
> >
> >
> > if (!good()) break;
> >
> >
> >
> > <Chris.Gorringe@r
> > acalinstrumentsgr
> > oup.co.uk>
> To
> > Sent by: <stds-scc20-
> atml@listserv.ieee.org>
> > owner-stds-scc20-
> cc
> > atml@ieee.org
> >
> Subject
> > RE: [Maybe spam] Common schema
> > 12/15/2005 04:07 units of measure - Use Option 2
> > AM plus
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > Units should always be units (defined in some standards somewhere) and
> > therefore we need to maintain a list of supported units
> >
> > We can add (either at the base class or by deriving types) historic
> units
> > Ins, ft, lbs, jerk etc. but these should ALWAYS be unit values
> references
> > to some standard
> > The modification or qualifier discussed I see needs to be available and
> > should include the following (taken from IEEE 1641-2004)
> >
> > trms (true root means square)
> > pk_pk (Peak to Peak)
> > pk (Peak)
> > pk_pos (Positive peak same as peak)
> > pk_neg (Negative peak)
> > av (average)
> > inst (instantaneous)
> > inst_max (instantaneous maximum value)inst_min (instantaneous minimim
> > value)
> >
> >
> > Note Peak values pk_pos, peak_neg, are w.r.t. the average value and are
> not
> > absolute values, i.e. a peak of pure sinwave is its amplitude removing
> and
> > DC-offset
> >
> >
> > The need for a free text 'modifier' is therefore to hold information
> which
> > is neither the 'Unit' or the 'quallifier' information examples of which
> I
> > would welcolme
> > Regards
> > Chris
> >
> >
> >
> >
> > **********************************************************************
> >
> >
> > IMPORTANT NOTICE
> >
> >
> >
> >
> >
> > The information contained in this e-mail is confidential. It may also
> >
> >
> > be legally privileged. It is intended only for the stated addressee(s)
> >
> >
> > and access to it by any other person is unauthorised. If you are not
> >
> >
> > an addressee, you must not disclose, copy, circulate or in any other
> >
> >
> > way use or rely on the information contained in this e-mail. Such
> >
> >
> > unauthorised use may be unlawful.>
> >
> >
> >
> >
> >
> > If you have received this e-mail in error, please inform
> >
> >
> > Racal Instruments Group Ltd. immediately by
> >
> >
> > emailing postmaster@racalinstrumentsgroup.co.uk
> >
> >
> > or
> >
> >
> > phoning +44 (0)1202 872800 (ask for the I.T. Dept.)
> >
> >
> > and delete it and all copies from your system.
> >
> >
> >
> >
> >
> > www.racalinstrumentsgroup.co.uk
> >
> >
> >
> >
> >
> > **********************************************************************
> >
> >
> >
> >
> >
> >