oslc-ccm message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Order of contributions in a configuration
- From: David Honey <david.honey@uk.ibm.com>
- To: oslc-ccm@lists.oasis-open.org
- Date: Wed, 9 Jul 2014 18:12:33 +0100
The current configuration management spec
at https://tools.oasis-open.org/version-control/browse/wsvn/oslc-ccm/trunk/specs/config-mgt.html
shows this for defining the order of contributions in a configuration:
Prefixed
Name
| Occurs
| Read-only
| Value-type
| Representation
| Description
|
oslc_config:contributionOrder
| exactly-one
| false
| String
| n/a
| An
indication of the order of the contribution, relative to other contributions.
Contributions are sorted lexicographically on this property to resolve
component skew. |
One of the issues with using a string
is to define what is meant by "sorted lexicographically".
Best practice in Java is to use a Collator for a specific locale. In which
case should this be the locale of the client, a consuming server, the contributing
server? This makes it very difficult for the provider of the contributor
to know how the order data it provides will be determined and whether it
represents the order used by that provider.
I have a suggestion to make this better
defined. What about requiring that the value uses an integer related xsd
type such as xsd:integer,
xsd:int,
xsd:long
and so on. That allows a precise locale-independent order to be defined
based on integer values. If we want to represent undefined ordering, then
perhaps the specification should make this zero-or-one
instead of exactly-one.
On the other hand, if the intent is that the contributions for every oslc_config:Configuration
must be fully ordered, perhaps the specification should define that each
contribution must have a unique value of oslc_config:contributionOrder.
In Java, most collators seem to be case-independent, such that the string
"ABC" has the same order value as "abc", "aBc"
and so on. That's another advantage for using a numeric integer datatype
instead of a plain literal.
Best regards,
David.
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]