[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]