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


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


Toby Considine
TC9, Inc.

Toby.Considine@gmail.com
Phone: (919)619-2104

http://www.tc9.com

  

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: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.


Toby Considine
TC9, Inc.

Toby.Considine@gmail.com
Phone: (919)619-2104

http://www.tc9.com

  

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 

 

 



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