RE: [unitsml] Suggested Schema Changes

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

All,

   Here's a quick response to Martin's two points.

1.) "Hectare" and "are" are included as separate enumerated
    root units because they are generally treated as separate
    units. For example "Hectare" is approved for use with the
    SI, while "are" is not. I believe the "centihectare" is
    used in some eastern European real estate documents. I
    know this all seems to defy logic, but so does much of
    human endeavor.

2.) In SP 811, two expressions are provided for derived units,
    one with based on other derived units and one solely with base
    units. I think the former would be preferable to the latter
    (since the latter can be obtained from the former). If this
    convention is followed, I don't see the need for multiple
    "RootUnits" elements. I think the value of allowing multiple
    combinations of units is outweighed by the risk of having two
    incompatible "RootUnits" elements.

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: Monday, July 13, 2009 4:07 PM
> To: unitsml@lists.oasis-open.org
> Subject: [unitsml] Suggested Schema Changes
> 
> Why would we want to stop changing our schema, it's so much fun!
> 
> I've noticed two things and am warning you ahead of time so you might
> give it
> a thought or two:
> 
> 1st: we have both 'hectare' and 'are' in our list of allowed values for
> the
> EnumeratedRootUnit element. But 'hectare' ist just hecto+are = 100 are.
> I'm
> not sure hectare should be in.
> 
> Suggestion (?): Remove hectare from list of EnumeratedRootUnits "unit"
> attribute.
> 
> 2nd: We have an optional RootUnits (0..1). We maybe should have it
> optional
> and potentially unbounded. Why is that? We need a sort of bracket to
> group
> together equivalent but different references to root units. Given that
> the use
> of EnumeratedRootUnit is encouraged to make it easier for both analog
> and
> digital readers of UnitsML content to infer that references to the same
> units
> are being made, first thoughts make it seem there should only be one.
> But what
> about following example:
> 
> Watt = Volt Ampere = Joule per second = Newton meter per second = Weber
> Ampere
> per second = Ohm Square Ampere = ...
> 
> Which of these is definitive? Actually without looking at the SPs I
> thought
> it's Volt Ampere but actually the term used in the SI is Joule per
> second. So
> obviously I was thinking "power" in terms of electronics. This same
> thing also
> can happen to other users of unitsml, lest we enforce a specific way to
> encode
> units. Oh, and btw, Watt also is "meter squared times kilogram per
> cubic
> seconds". Is that wrong?
> 
> I don't think we can with good conscience enforce one of these ways,
> and also
> people might be interested to include more than one reference to other
> units
> in their unit declarations (in the watt example, maybe Nm/s and VA).
> For this
> we'll need multiple RootUnits.
> 
> Suggestion (?): Allow RootUnits to be unbounded
> (maxOccurs="unbounded").
> Document in Guidelines that we expect users of multiple RootUnits
> elements to
> specify entries that ultimately reduce to the same expression in terms
> of [SI]
> base units.
> 
> Apologies for writing so much again :)
> 
> -Martin
> 
> ---------------------------------------------------------------------
> 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