OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

obix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [obix] Schema Changes for OBIX

Toby and Craig and the list --

I've been trying to get WD41 out, and the conversation below is THE key issue in https://issues.oasis-open.org/browse/OBIX-238 .

The spec uses "contract list" or "Contract List" informally, but it's not a first class type. I see a fair amount of confusion where the reference (a URI or URI list) is conflated with the thing referenced.

The good news is that understanding that most things require a list, and fixing the type contract in Figure 4-1 also fixes most of the issues that I've had; the only change (avoiding the serialization issue) is that "contract" cannot be a URI and be the in and out for Op (for example).

Toby's formulation suggests that there a type/class "contract", of which contract is a global element in XSD; that makes the various places work and for the UML, I'd define contract (rather than the NIEM style ContractType) to have a single element which is

    contractElement [0..*]: anyURI

with the constraint as Toby listed (if there is zero, you really need "Nil" as the first)

This does not fit usual typography for class and element names, however.

Then the types for in and out are "contract" as in the original Figure 4-1.

I still prefer having ContractList as the actual type, with 0..* contracts of type anyURI; this is how people use XML usually. See 4.2.3 and a lot of section 4.

All Objects MAY have the is attribute.  This attribute defines the Contracts this Object implements.  Contracts are discussed in Section 7.  The value of this attribute MUST be a Contract List, which is described in detail in Section 7.2.

ContractList (no spaces) was used in section 7.2, but elsewhere is called Contract List. I used the version with the space for description. Again, the type in the schema for e.g. in and out is "contract", not ContractList.  This suggests that the type should be ContractList, but it's contract instead. This seems ripe for confusion over time.

I've fuzzed this up in the attached diagram (also deals with the null initialization) which is the new Figure 4-1 (which also is part of the List of Figures correctly now).

One other detail I found: "Contract Object" is used only in section 7; it's not in section 4 where I'd expect it if that's the proper term.

WD41 has the updated UML diagram. It's not a major update. See the notes included. Minor editorial changes; with the UML tweaks most of it makes more sense. I don't have time to post a diffmarked version wrt WD40.



On 4/22/15 10:12 PM, Toby Considine wrote:

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.





"There are seldom good technological solutions to behavioral problems."

-- Ed Crowley

Toby Considine
TC9, Inc.

Phone: (919)619-2104



Chair, OASIS OBIX Technical Committee

Chair, OASIS WS-Calendar Technical Committee

Editor, OASIS Energy Market Information Exchange (EMIX)
Editor, OASIS Energy Interoperation
blog: http://www.NewDaedalus.com 



From: Gemmill, Craig [mailto:craig.gemmill@tridium.com]
Sent: Wednesday, April 22, 2015 8:44 PM
To: Toby Considine; obix@lists.oasis-open.org
Subject: RE: [obix] Schema Changes for OBIX


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.



From: obix@lists.oasis-open.org [mailto:obix@lists.oasis-open.org] On Behalf Of Toby Considine
Sent: Wednesday, April 22, 2015 4:38 PM
To: obix@lists.oasis-open.org
Subject: [obix] Schema Changes for OBIX


Based on the last three meetings, I propose changing the XSD definition of “contract” as follows:


            <xs:simpleType name="contract">


                                    <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:restriction base="xs:string"/>



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.

Toby Considine
TC9, Inc.

Phone: (919)619-2104



Chair, OASIS OBIX Technical Committee

Chair, OASIS WS-Calendar Technical Committee

Editor, OASIS Energy Market Information Exchange (EMIX) Editor, OASIS Energy Interoperation
blog: http://www.NewDaedalus.com 



Attachment: Obj and Subclasses20150422.png
Description: PNG image

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]