-------- Forwarded Message --------
Toby, Craig, and all --
I've run into some complexities in section 7 so didn't do a full
See attached PDF of just section 7 for consideration Thursday
(from the incorrectly labeled WD41 (the footers and title say
WD40). The entire docx, changed only in header and section 7, is
also attached. Please use the PDF for discussion and comments.
These are key areas for Contract Element and Contract changes.
I've also re-included the updated final UML diagram - see
questions below and changes in section 7.
On 4/29/15 8:29 PM, William Cox
I've attached the completed UML diagram based on Toby's schema
I will finish up a new WD after dinner (yes, it's late dinner)
and post tonight.
Some issues with the UML and wd41 schema:
(1) Most items are XSD atttributes, hence optional by default
(is there XSD cardinality for attributes? not sure). This leads
to some strange things:
Bool, for example: the value is optional (val [0..1') but is
initialized to false. Likewise Real val = 0 but is optional
Many instances (artifacts) would conform with nothing at all
in them except the type name. Seems odd.
(2) some type names are lower case in the schema. That means
that Obj.status is of type status ("status: status = ok" -
showing initial value).
(3) related: contract is lower case, but it might well be a
global element or attribute of ContractType (not defined).
(4) in List, the initial value for of is "OBIX:obj". First, I
think that that's the namespace identifier in the schema, and it
should be "obix:obj" as in earlier schema drafts. Second, why is
obj lower case? Again conflates the names for global attributes
with type names. Is this another "distinguished value" such as
(5) I think that leaving the UML stereotypes for XSDattribute
and XSDelement is very useful to the reader. In the previous
version I'd manually deleted them.
Working along, will publish tonight.
+1 862 485 3696 mobile
On 4/29/15 4:28 PM, William Cox
Thanks for the update. I think the most productive path
forward is for me to clean up the diagram (attached to my
earlier email), insert in a new WD42, and make the touchups
needed to have the updated "contract" definition make sense.
I'll do that and post tonight; no need for you to work on the
Toby, does that work?
BTW the draft schema was directly reverse-engineered into the
diagram, and I think is much more clear. I'm going to leave
the XSDattribute/XSDelement stereotypes in the UML as it'll be
more clear to those using XML.
On 4/29/15 12:39 PM, Gemmill,
apologize, I have not been able to get to the WD42
yet. If you want to go ahead with a discussion on
WD41 tomorrow, that would be fine. I’m not sure we’ve
discussed everything that we had on the queue last
week anyway. I hope to at least be able to go over
WD41 to be prepared for a discussion, but it would be
tonight before I got to it.
Nil & list of URIs was in 1.0, I had not really
changed any of that behavior, IIRC.
not totally sure the contract stuff is right though.
I've attached the WD40 diagram dated 20150422 and a work
in progress on WD41.
Should I touch up the document now that we've moved
toward resolution? Do we need further discussion first?
Does this all work for you? I'm not sure what the 1.0
behavior is; was the list-of-URIs and Nil a 1.1
innovation? Was it in 1.0 or 1.0 extensions?
Here's a partial update to the UML - from
reverse-engineering the WD41 schema. Due to oddities
in the Enterprise Architect UML tool I have to do some
hand updates to the attributes - for example, in Op
the attributes will be
The initialization to Nil in the WD41 XSD is not yet
reflected - again has to be manual.
The terminology is
Contract - The relevant agreement for a specific
purpose, e.g., for Feed "in" and "of" are of type
Contract. The XSD type is String. The string
contains one or more URIs separated by spaces. If the
initial URI is the string "Nil" the Contract is
treated as empty. The initial URI element has special
meaning - see section XYZ.
+1 862 485 3696 mobile
On 4/26/15 6:56 PM, Toby
Much of the conversation since
February has been around the confusing and
inconsistent use of Contract and ContractList. This
is compounded by the “is” and the “of” which are
“formatted as a contract list”
As I can best summarize the
A ContractElement is an URI.
A contract is a string consisting
of 0-to-many space delimited ContractElements.
If a Contract consists of 0
(zero) ContractElements, then by convention it is
represented with the reserved string “nil”
There is some language that
suggests that the first contract element in a
contract has some sort of special or primary value,
but it is not yet clear to me precisely what this
I believe that this language, and
this description, if applied across all the areas of
the specification document that use the term
“Contract” will remove the last inconsistencies in
The Schema WD41, recently
uploaded, reflects this change.
single biggest problem in communication is the
illusion that it has taken place.”
George Bernard Shaw.