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 [1], that
it looks as if it is anyURI, and that when the number of
members is [0], 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.
tc
"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:simpleType
name="contract">
<xs:annotation>
<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>
</xs:annotation>
<xs:restriction
base="xs:string"/>
</xs:simpleType>
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?
tc
“The
single biggest problem in communication is the illusion
that it has taken place.”
– George Bernard Shaw.
