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


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