OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

unitsml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]