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

 


Help: OASIS Mailing Lists Help | MarkMail Help

unitsml-comment message

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


Subject: Comments on Guidelines version 0.4


Part 1: please add "business" or a specific field of business (e.g., 
shipping businesses) to the list of communities that could use UnitsML. 
Introduce the notion of other consortia, particularly business consortia, 
being able to have their own equivalents of UnitsDB - more on that below.

Part 2: I think Namespaces in XML will belong on the list. How about the 
OASIS Code List standard?

Part 3: Add "Dimension" and some variation of "Value" (Measured Value? 
Numerical Value?)

Part 6: In the introductory section, change "scientific units" to just 
"units".

Part 6.1: Expand the title "NDR" into words.

Part 7.1: Not sure what "be used containing descriptions" was supposed to 
say.

Part 7.6: Could the text in the SpecialConversionFrom element be a URL? If 
so, would it be helpful to allow for an attribute or some flag to 
designate what to do with the URL?

Part 8.1: Erroneous reference to example 7.0 should be 8.0, I think.

Part 9: I hope that this section could provide guidance to other consortia 
about how they can define their own units. To begin with, explain what one 
would obtain by querying UnitsDB. The same XML format should apply to 
similar data from industry consortia, but with certain important concerns:
A. Presumably, the consortium would only define non-base units, and 
provide a conversion to base units. For example, a printing industry 
consortium might have a unit of length called a "point" and provide the 
conversion to meters as a multiplicative factor.
B. The consortium should use namespace-qualified names for their units, so 
the UnitsDB response format should be designed to carry namespace 
declarations.
C. The definition might change, so there should be a provision to 
time-stamp the returned data. (I think this is under the UnitNote.)

Part 10: I think UnitsML sets the foundation for treatment of currencies. 
This is especially useful for expressing variable fees charged as (numeric 
value) (currency identifier) per (measured quantity), where
the latter is clearly in the UnitsML domain. Note that the "per" 
relationship is also in UnitsML territory. This section of the document 
could specify the work that some *other* Working Group would need to do to 
bring currencies and costing into the mix.


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