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


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