RE: [unitsml] Three motions

["Legrand, Karen" <Karen.Legrand@iem.com>]

I also vote for all 3 motions.

-----Original Message-----
From: Legrand, Karen 
Sent: Tuesday, February 01, 2011 5:48 PM
To: 'Weber, Martin S.'; unitsml@lists.oasis-open.org
Subject: RE: [unitsml] Three motions

I second all three of these motions.

Karen Legrand

-----Original Message-----
From: Weber, Martin S. [mailto:martin.weber@nist.gov] 
Sent: Tuesday, February 01, 2011 4:39 PM
To: unitsml@lists.oasis-open.org
Subject: [unitsml] Three motions

Hello TC,
[this message is to be recorded as part of the asynchronous portion of
the January UnitsML OASIS TC meeting]

I do apologize for having these motions so late during the asynchronous
portion of the TC meeting, but we might still get them through before
the meeting ends tomorrow midnight.

So here we are (rationales below):

1) I move that the "ItemVersionHistory" child element of the
"CountedItem" element be moved behind the "ItemSymbol" element.

2) I move that the "UnitVersionHistory" child element of the "Unit"
element be moved behind the "QuantityReference" element.

3) I move that if either or both of above motions get seconded and pass,
we designate the resulting Schema as a new Committe Specification Draft
(please keep in mind that, if this motion also gets seconded, we need a
special majority vote, i.e., everybody needs to explicitely voice a
"yes" or "no").

Rationale for 1):
Bob and I have noticed that the ItemVersionHistory element is stuck
between the ItemName and the ItemSymbol elements. Given that the
encompassing structure is a sequence, this means that a UnitsML author
has to go through this "hiccup" of designating a name, then entering the
version history of the item (if present), and only then can designate a
symbol for the counted item. I believe that grouping "name" and "symbol"
together is more logical. This approach can also be seen in the Unit
element (Name and Symbol are grouped together)

Rationale for 2):
Unit's child elements also can be clustered such as: a) describing the
unit itself, b) describing the unit's relation to other units and
quantities and c) meta-data about the unit in question. Currently the
UnitVersionHistory somewhat stands in the middle. When looking at the
Quantity element for comparison, the QuantityVersionHistory follows the
UnitReference element, leaving the following setup for the quantity: a)
descriptive elements, b) elements describing the quantity's relation to
units (UnitReference) followed by c) meta-data. I think that moving the
UnitVersionHistory behind the QuantityReference would nicely mirror the
setup of the Quantity element. (Keep in mind that the Unit's child
elements also reside in a sequence, so order does matter).

Rationale for 3):
Our current Committe Specification draft would remain standing out there
even if we update the schema. To have the CSD reflect the latest
changes, we need to vote another time on the schema. So if at least one
of the above motions pass successfully, we should make this draft
version the official CSD. And we still can do this during this meeting.

Apologies again & with regards,

-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