I think we just need to clarify the uses of Contract. The more I think about it, the more I think we really should keep the terms
Contract for the URI referencing a single object used as a template, and
Contract List for a sequence of these URIs. The confusion over the use of Nil is because we are not clearly explaining the concept of contract inheritance I think.
Looking at the object hierarchy diagram, and identifying the places where the term ‘contract’ is in play:
Op.in (default =obix:Nil)
Op.out (default =obix:Nil)
Feed.in (default =obix:Nil)
Feed.out (default =obix:Obj)
Obj.is (no default)
For the first five items, if the attribute does not appear in an instance of this object, then the default is used, which is unambiguous. Obix:Obj is one object template; obix:Nil is simply another object template.
There is nothing special about obix:Nil. All of these are just a sequence of Contracts, which MAY be empty. If the is attribute is not present, then the object derives directly from obix:obj.
Bill has a comment that the terminology is difficult to make clear. I think that is because of the switch from naming “thing” and “group of things” to naming “thing” and “parts of the thing”. I think our best
bet is to continue with Contract/Contract List, and then to be more explicit about where Contract List should be used instead of Contract.
We can discuss today.
From: firstname.lastname@example.org [mailto:email@example.com]
On Behalf Of Gemmill, Craig
Sent: Wednesday, May 13, 2015 4:05 PM
To: Considine, Toby; William Cox; firstname.lastname@example.org
Subject: RE: [obix] Contract questions
The renaming is all that I could see was happening with the previous discussion. If the things I think of as ‘apples’ are known as ‘oranges’ to everyone else, I am fine to start calling the ‘oranges’; it does
not change what they are. I didn’t see that there was any fundamental change in the objects from our discussion. There is still a single thing which references an OBIX object by its URI. Then there is a space-separated sequence of these things. The sequence
is what is the value of the “is” attribute. It still just seems simpler to call them “contract”, and “contract list”, respectively.
I think you [Craig] are renaming the existing complexity rather than reaching through to simpler language. Probably too close. Forest / Trees.
“It is the theory that decides what can be observed."
Information Technology Services
University of North Carolina
Chapel Hill, NC
Chair, OASIS OBIX Technical Committee
Chair, OASIS WS-Calendar Technical Committee
Editor, OASIS EMIX, Energy Interoperation TC
I think this is making it more complex than needed.
Where the text now says "Contract" you almost always mean "Contract List". And that's how I'd suggest saying it.
Only when you talk of the structure of the attribute of say Op:in would you say "contract list" or "contracts". Capitalized is the definition, lower case is the set.
I don't think it's a "Contract Sequence". It's a list, as the WD41 text says, but the TYPE was "Contract".
The schema is close IMO.
On 5/12/15 4:49 PM, Gemmill, Craig wrote:
I’m trying to put together WD42, based on my (unfortunately incomplete) notes from last meeting’s discussion.
One of the discussion points was about the names “Contract”, “Contract Object”, and “Contract List”. I thought I was okay with the name change of
Contract -> Contract Element
Contract List -> Contract
Contract Object being fully defined.
This seems to help minimize the ambiguity over whether a Contract List is an obix:list (it isn’t). However, this vocabulary becomes quite cumbersome, because then, everywhere in the specification where it talks about “Contracts”, we now
need to say “Contract Elements”. It makes the wording sound rather awkward to me.
So, I would propose we not do that. It really seemed to me to just be a name change anyway, as the concepts are essentially the same. The compromise I would suggest is to come up with a different name for “Contract List”, using a synonym
for the word ‘list’ to make it clear this is not an obix:list. I thought it would be a little easier to find an appropriate replacement than it this (‘Contract Gazette’ doesn’t quite work, I think), but maybe something like ‘Contract Group’, or ‘Contract
Sequence’ would work.
I can post a WD42, probably tomorrow, but it would likely be incomplete, as I am not sure it’s worth changing Contract to Contract Element everywhere. Just read the beginning of Section 7 with this change…
Also, regarding the definition of ‘Contract Object’, I believe Contract Object is the same thing as Contract Definition. When I went to write up the definition, I saw the best definition staring me in the face, one line above. So, I propose
changing instances of Contract Object to just be Contract Definition.
I would like to meet Thursday. If I get feedback on this, I’ll make the change. Otherwise, I may just try to make changes for the remaining JIRA issues. I believe that I had questions on several other issues to discuss last time, but
we spent the entire time talking about the Contract issue so they missed out.