Next in thread →
Next in month →
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
REF _Ref98830598 \r \h 7. The value of this attribute
MUST be a
Contract List, which is described in detail in Section
REF _Ref130008028 \r \h 7.2.
JA
X-NONE
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.
Thanks!
bill
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.
tc
"There
are seldom good technological solutions to behavioral
problems."
--
Ed Crowley
Toby
Considine
TC9, Inc.
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:]
Sent: Wednesday, April 22, 2015 8:44 PM
To: Toby Considine;
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:
[mailto:]
On Behalf Of Toby Considine
Sent: Wednesday, April 22, 2015 4:38 PM
To:
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.
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
Attachment:
Obj and Subclasses20150422.png
Description: PNG image
Next in thread →
Next in month →