Re: [unitsml] prefix (symbols) & languages

["Linstrom, Peter" <peter.linstrom@nist.gov>]

All,

   This message is also intended to be part of the asynchronous
UnitsML meeting for February.

    I can only see one reason why we might not want the xml:lang
attribute in prefixes: the SI / IEC define fixed symbols which
are supposed to be language independent. I don't know how XML
processors treat elements where the xml:lang element exists, but
is not specified. If the absence of the element means "it applies
to my language", then we are OK. Otherwise we might have to put
in entries for the standard prefixes in many languages (English,
Spanish, French, German, Italian, Nauhuatl, etc...). I would
appreciate it if someone could indicate if this would be an issue
or not.

   Maybe I am missing something, but I don't see the point of
changing the way the prefixes are handled in the RootUnits
element. The purpose of root units to declare the composition
of derived units. For interoperability purposes there are
sets enumerated prefixes and units which (hopefully) will
cover a large number of units encountered in practice. None
of this is dependent on the representation of the base
units or prefixes. The fact that the prefix is named "G" is
just a convenience for (non-Russian) software developers.
Software can refer to that prefix as "G", "giga", "O", "10e9"
or whatever else they want. I think the important thing
is to have an enumerated set of prefixes. Allowing arbitrary
prefixes in RootUnits would create the potential for abuse
(conversion factors in RootUnits) and increase the complexity
of software required to process UnitsML.

Peter


======================================================
Peter J. Linstrom
(301) 975-5422
NIST, Chemical and Biochemical Reference Data Division
======================================================



> -----Original Message-----
> From: Martin S. Weber [mailto:martin.weber@nist.gov]
> Sent: Thursday, February 18, 2010 3:00 PM
> To: unitsml@lists.oasis-open.org
> Cc: Deborra J Zukowski; Joseph.F.Solsky@usace.army.mil
> Subject: [unitsml] prefix (symbols) & languages
> 
> Hi everybody,
> (this message, as usual, shall be part of the asynchronous portion of
> the thus
> now official oasis unitsml february meeting).
> 
> The following is a followup/detail of points 5b) and 5c) on the Agenda
> for the
> february meeting; these points were initially encountered by Karen
> Olsen when
> working on the UnitsDB; yet although it's more of an implementation
> issue,
> UnitsML itself would IMO profit from it, too.
> 
> The question at hand is: Should prefix symbols gain an xml:lang
> attribute? And
> related to that, which values should be accepted in the
> RootUnits/EnumeratedRootUnit/@prefix attribute?
> 
> The origin for the first question actually comes from the russian
> language,
> which seemingly uses some different prefixes than the standard SI
> prefixes. By
> adding in an xml:lang attribute, one prefix element could have multiple
> prefix
> symbols in different languages, thus making internationalization
> easier.
> (Multiple symbols are already possible; multiple and language tagged
> names for
> prefixes are also possible already). We agreed in the meeting that
> adding an
> xml:lang to the Prefix/PrefixSymbol is a good idea.
> 
> ...which brings us to the second question: In the light of then
> different
> available prefix symbols, should we stick to the enumerated list of
> standard
> SI prefixes on the prefix attribute of the  EnumeratedRootUnit element
> (child
> element of RootUnits, used to derive units)? Or in other words, if your
> preferred, say, "Giga" symbol is "O" (whatever :)), wouldn't you also
> want to
> derive a unit from giga-something by specifying "O" as the prefix? This
> led to
> a discussion about whether to allow any token (or string, or number) at
> the
> prefix place of the EnumeratedRootUnit.
> 
> The least ambiguous surely would be to fill in a number (e.g. prefix
> 1024),
> but then questions about the format arise, (1000000000000000 vs 1e15
> and what
> about 1099511627776 (tebi), 1b12?); also having the predefined prefixes
> there
> in an enumeration is a good help for unitsml processors; this way they
> can
> offer users a selection of "accepted" prefixes.
> 
> So we shouldn't drop the enumerated list of prefixes. Questions
> remaining:
> - prefix symbols or prefix names? We figured prefix symbols are more
> easily
> recognized than prefix names
> - what about the non-standard prefix symbols/names? How do they fit in?
> Well,
> my suggestion was to create an xsd:union with either an xsd:token (any
> single
> word thing, with a leading alphabetical character and following
> alphanumerics
> basically) or an xsd:string (any string whatsoever) for this attribute
> and
> keep the enumeration. This might weaken the use of the predefined
> symbols, and
> might make life harder for unitsml processors (or their implementors),
> but
> given the predefined symbols still are there, I suppose most people
> still
> would use them. This could be the right degree of freedom for this
> attribute... what do you think?
> 
> Here is how the relevant schema snippet could look like:
> 
> <!-- in definition of unitsml:EnumeratedRootUnitType -->
> <xsd:attribute name="prefix">
>    <xsd:annotation>
>      <xsd:documentation>Prefix identifier; e.g., m, k, M, G.
> [Enumeration
> order is by prefix magnitude (Y to y) followed by binary prefixes.]
> Additionally any other "sensible" form of a prefix is allowed (e.g.
> 1000000,
> 1024, mega, ...)</xsd:documentation>
>    </xsd:annotation>
>    <xsd:simpleType>
>      <xsd:union memberTypes="xsd:string xsd:number">
>        <xsd:simpleType>
>          <xsd:restriction base="xsd:token">
>            <xsd:enumeration value="Y"/>
>            <xsd:enumeration value="Z"/>
>            <xsd:enumeration value="E"/>
>            <xsd:enumeration value="P"/>
>            <xsd:enumeration value="T"/>
>            <xsd:enumeration value="G"/>
>            <xsd:enumeration value="M"/>
>            <xsd:enumeration value="k"/>
>            <xsd:enumeration value="h"/>
>            <xsd:enumeration value="da"/>
>            <xsd:enumeration value="d"/>
>            <xsd:enumeration value="c"/>
>            <xsd:enumeration value="m"/>
>            <xsd:enumeration value="u"/>
>            <xsd:enumeration value="n"/>
>            <xsd:enumeration value="p"/>
>            <xsd:enumeration value="f"/>
>            <xsd:enumeration value="a"/>
>            <xsd:enumeration value="z"/>
>            <xsd:enumeration value="y"/>
>            <xsd:enumeration value="Ki"/>
>            <xsd:enumeration value="Mi"/>
>            <xsd:enumeration value="Gi"/>
>            <xsd:enumeration value="Ti"/>
>            <xsd:enumeration value="Pi"/>
>            <xsd:enumeration value="Ei"/>
>            <xsd:enumeration value="Zi"/>
>            <xsd:enumeration value="Yi"/>
>          </xsd:restriction>
>        </xsd:simpleType>
>      </xsd:union>
>    </xsd:simpleType>
> </xsd:attribute>
> 
> Regards,
> -Martin Weber
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php