[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [obix] Schema Changes for OBIX
It is my recollection that we cancelled tomorrow with both Bill and Craig missing.
Next full meeting is in a week. New draft by Bill comes out today so Crag can create a new draft early next week, in time to allow 48 hours of review by the meeting.
The distinction between contract and Contract List is one that has bedeviled us since February. We see to have reached the following conclusions last week (and in February)
1) We claim that Contract is of the form anyURI
2) Whenever there is a Contract there may be a Contract List
3) A Contract List is a set of anyURIs separated by spaces
4) If the List of Contracts is empty, the form of the string is “nil”
5) The first Contract in a Contract List, i.e., the first anyURI in a space delimited set of anyURIs is special
Ideally, in a format that is not backwards compatible, this would be an XML list of contracts objects. That is not what we have, that is not what the artifacts display.
What we have in the Artifacts appears to be solely a ContractList. Logically this is a set of 0-to-many contracts. This makes the UML much cleaner. In XSD, we have a string with parsing rules as described in the Spec.
The parsing rules suggest that the constrained is *always* a contract list, that when the number of members is , that it looks as if it is anyURI, and that when the number of members is , it is expressed as “nil”
The realization that it is always a contractList looks as if it will make many of the odd special explanations in the spec contract.
"There are seldom good technological solutions to behavioral problems."
-- Ed Crowley
I thought we said contract was one thing, but contract list was 0-many? It’s interesting that is used to be type contract, but was changed somewhere along the line to string.
Also, I have a delivery and service tech visit tomorrow, so I probably will miss the ‘workshop’ call.
Based on the last three meetings, I propose changing the XSD definition of “contract” as follows:
<xs:documentation> This is a contractList, i.e., 0-many URIs. In XSD, it is a string because the collection of URIs follows special serialization rules, i.e., URIs are space separated, and the zero length list is specified as "nil", See the specification for details.</xs:documentation>
If this is acceptable, then IS should be changed to be of type “contract” from the type “string” that it is now.
Perhaps the same applied to “in” and “out”
Is this correct?
“The single biggest problem in communication is the illusion that it has taken place.”
– George Bernard Shaw.