Ludo -
Thanks for following up. This email has current (and updated)
issues with the XSD, text, and UML.
After the 25 Sept meeting, I went back to XSD types as UML
primitive types are not particularly known in the XML community.
We also discussed the other issues. Look at follow up emails on
25 September particularly to the TC list at 11:38am Eastern
time.
So there were numerous small changes after the email quoted
below all reflected in later email.
INT INTEGER etc
"Int", "int", or "integer"?
We're using XSD types, and in XSD, definition is: int
-2147483648, ... -1, 0, 1, ... 2147483647
That's what's in the schema, so that's what should be in the UML
diagram (implicit xsdTypes package::int). Corrected the
remaining "integer" types to "int" for consistency.
Note: "integer" is also a standard XSD type; it's not limited in
range as long and int are.
So should it be "long" or "int" or "integer"? Depends on what
the schema users expect, and it controls so the spec should
match the schema which should match the spec :-)
Capitalized "Int" is an obix type, class "Int" on the upper
right hand side of the UML diagram and in the schema:
<xs:complexType name="Int">
<xs:complexContent>
<xs:extension base="Obj">
<xs:attribute name="min" type="xs:int"/>
<xs:attribute name="max" type="xs:int"/>
<xs:attribute ref="unit"/>
<xs:attribute name="val" type="xs:int"
default="0"/>
</xs:extension>
</xs:complexContent>
ERROR in heading for "4.3.1.2 int" is really muddled. val maps
to xs:long, NOT xs:int. So the schema should say xs:long NOT
xs:int. And so should the UML.
ACTION Toby fix schema, Bill fix UML.
CLASS NAMES:
wd36 line 324 says the root abstraction is "Object" (note
capitalization). This is used consistently in the XSD
documentation. The text on 324-325 seems incorrect.
BUT the schema on line 265 defines the type as "Obj" with a
global element "obj" (as usual).
CARDINALITY of "is" attribute: line 344 says "...the Contract
S
this Object implements" (note plural "Contracts"). XSD line 202
implies 0..1 (typical attribute cardinality).
ACTION: The text should be corrected on line 324 to make
singular.
ENUMERATIONS:
Toby said in a meeting that he didn't think there were
enumerations. Look at <<enumeration>> status
(disabled, fault, down, ...). ACTION: None. No changes needed.
OTHER ISSUES:
From my earlier email
obix:obj is used in the same way; same
issues - but it's a defined element of type Obj. Confused.
It's a default for contract.
"contract" is explicitly defined as of type "anyURI". See "Op".
It's also an xs:any in a different
namespace with lax process Contents. Huh? "contract" is an
alias for "anyURI" so how come it's xs:any in several places??
Note the use of "any" in Obj in the sequence. This is not
reflected in the UML.
schema wd36:
<xs:complexType name="Obj">
<xs:sequence>
<xs:element ref="obj" minOccurs="0"
maxOccurs="unbounded"/>
<xs:any namespace="##other"
processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute ref="display"/>
<xs:attribute ref="displayName"/>
<xs:attribute ref="href"/>
<xs:attribute ref="icon"/>
<xs:attribute ref="is"/>
<xs:attribute ref="name"/>
<xs:attribute ref="null"/>
<xs:attribute ref="status" default="ok"/>
<xs:attribute ref="ts"/>
<xs:attribute ref="writable" default="false"/>
</xs:complexType>
On 10/16/14 12:08 PM, Ludo Bertsch wrote:
Bill,
cc: Toby,
Find below the list of issues I was talking about on the call
today, that I am not sure has been dealt with yet.
I did a quick check of one of the items , "Int", in WD36, and as
far as I can see, the issue is still there.
Cheers,
Ludo
On 9/24/14 11:46 PM, William Cox wrote:
Craig and Toby --
I've attached the WD31 UML diagram as a 400dpi PNG. Scale as
needed to fit in the spec.
I used the obix-v1_1_WD31.xsd Toby uploaded to produce this.
The beautification attempt cannot be blamed on the schema.
There are some modeling issues:
(1) The XSD types are embedded in the earlier diagram; I've
done the following:
- Used the UML primitive types for Boolean, String,
Integer, Real instead of boolean, string, int, and double
- Used the XSD NMTOKEN and anyURI (these should probably
both be conformed Strings)
- Left the XSD dateTime and date and time types - I could
define those as in the WS-Calendar PIM as conformed
strings; that's what they are, but I don't think that
level of persnicketiness (sp?) is useful
- obix:Nil is used only as a literal default/initial value
and seems otherwise undefined. Not sure whether this is an
issue in the XSD
- obix:obj is used in the same way; same issues - but it's
a defined element of type Obj. Confused. It's a default
for contract. It's also an xs:any in a different namespace
with lax process Contents. Huh? "contract" is an alias
for "anyURI" so how come it's xs:any in several places??
(2) I note that several classes have additional attributes
and there are some related issues.
- Should ts have a default value of "" (the empty string)?
- Enum has "range" added
- Int has added "unit"
So this diagram is pretty close to valid UML; the gaps are
dateTime, date, time, etc (easy to fix if it needs to be
fixed). The use of obix:obj and Nil need discussion. And
perhaps (since the xsd is the basis) I should go back from
the UML types to the XSD types for boolean, int, etc.
Thanks!
bill
--
Ludo Bertsch, P.Eng.
Horizon Technologies
www.horizontec.com
ludob@horizontec.com
(250) 592-1488
This email may contain confidential information and is directed at the
recipient only and is not to be disclosed to anyone else without
permission. If you have received this email in error, please
inform us and delete this email and attachments. Please let us
know if you no longer wish to receive emails from us.