obix-xml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [obix-xml] Schema
- From: "Brian Frank" <bfrank@tridium.com>
- To: "Jeremy Roberts" <jeremy@lonmark.org>,<obix-xml@lists.oasis-open.org>
- Date: Tue, 30 Nov 2004 10:51:03 -0500
Great comments Jeremy.
My responses/opinions
below....
-----Original Message-----
From: Jeremy Roberts [mailto:jeremy@lonmark.org]
Sent: Monday,
November 29, 2004 7:39 PM
To: obix-xml@lists.oasis-open.org
Cc:
Don.Delaurier@Edwards.spx.com;
ganesh.markale@honeywell.com;
Jeff.VanKeuren@Edwards.spx.com;
kirkatcaba@sympatico.ca; Brian Frank;
Aaron Hansen
Subject: RE: [obix-xml]
Schema
Gang,
First, I'm sorry that schedule has been in
conflict with the meetings as of
late. I have been trying to keep-up
offline on the progress.
I like the proposed schema a great deal.
Reviewing it, I have some
questions/suggestions (and please forgive me: I
know most of this was in the
document as how they should be represented, so
my comments are really
related to the document as much as the schema
representing it):
<xs:element name="int" type="xs:long"
/>
[§2.5.2 int] We are saying here that "int" _is_ long, but
xs:long is based
on xs:integer (which is based on xs:decimal). When in
fact, xs:int is
_based_ on xs:long. I think we should lean toward the
use of something
similar to the name "long" if it's xs:long that we want to
represent.
The intent was to have a simple
set of primitive types that didn't obviously collide with with XML Schema.
However you can't pick a term for integer that doesn't collide, so we just
picked int to mean the standard type for integer values.
---
<xs:element name="str"
type="xs:string" />
[§2.5.4 str] Do we intend to allow CR/LF and
tabs in these strings? If
not, we should use xs:normalizedString
instead (otherwise, it's fine to me).
I think we should stick with
xs:string myself; I think newlines will be used.
This question
applies to parts like, for example:
<xs:complexType
name="UnitType">
<xs:attribute name="id"
type="xs:string" />
<xs:sequence>
<xs:element name="id"
type="xs:string" />
<xs:element
name="display" type="xs:string" />
<xs:element name="symbol" type="xs:string" />
These items seem like
they should be restricted; and in these cases, typed
to xs:token instead of
xs:string, so that they have no leading/trailing
spaces or double spaces, nor
CR/LF and tabs. Strong typing will prevent UIs
from breaking due to
lack of such typing.
I could go either way, although
personally I think using xs:token makes
things more complex because now
you really have to understand how
string normalization occurs versus
sticking to simple string comparisions.
---
<xs:element name="scale"
type="xs:double" default="1" />
<xs:element name="offset"
type="xs:double" default="0" />
[§2.6.8 units] These are typed
as xs:double, but that means the interpreter
needs to support 64-bit
double-precision floating-point numbers. For
scaling, even xs:decimal
is more than we would likely ever need (18 digits),
but I think it's better
than xs:double. As an alternative, we could have a
"multiplier" and
"powerFactor" replace the "scale" element. Those could be
typed as
xs:byte, to prevent a scaling factor outside of -1.27E-125
and
1.27E+129. It amounts to the same, but decimals do not become an
issue, and
the computation becomes easy using the typical...
rawValue
= ((scaledValue / (multiplier * (10^powerFactor))) - offset)
scaledValue =
(multiplier * (10^powerFactor) * (rawValue + offset))
Also, the scaling
then becomes limited so numbers like 3.16227766 cannot
exist (multiplier of
1, powerFactor of 0.5, where rounding of numbers is
needed to come close to
the intended values).
There are a few other xs:double types defined that
we may wish to examine.
I think expressing things are 64-bit doubles on
the wire is the correct way to normalize. I don't think that
necessarily requires that the parser maps the value to a 64-bit double in
software.
---
[§2.7 Units] The "seven fundamental dimensions" may be
insufficient to
cover everything that needs to be covered in an
building-control market.
Measurement dimensions like turbidity cannot be
represented by mole (mol),
and candela (cd) without some very creative tables
for substances. It would
also serve us well to include percentage as a
fundamental dimension, since
it is used as though it were a unit unto
itself. At the moment, I cannot
recall others, but I will address them
with you as the trickle to the
forefront of my noggin.
You are correct - it is insufficient to
model everything. But that is by design. Anything can be modeled
with a dimension of all 0 exponents, you just can't do auto-conversions with
those values. For instance you can model units defined in terms of angles
or logs, but you can't model their dimension. To me it is a tradeoff of
simplicity for the common cases versus complexity to create a model that handles
everything.
---
Great job on the schema. I think it
does a great job of encapsulating the
document.
Talk to you all on the
1st,
Jeremy ROBERTS, LONMARK International
TEL:
+1-215-918-1026
________________________________________________________________
-----Original
Message-----
From: Brian Frank [
mailto:bfrank@tridium.com]
Sent: Friday,
November 19, 2004 3:26 PM
To: Aaron Hansen;
obix-xml@lists.oasis-open.org
Cc: Don.Delaurier@Edwards.spx.com;
ganesh.markale@honeywell.com;
Jeff.VanKeuren@Edwards.spx.com;
kirkatcaba@sympatico.ca
Subject: RE: [obix-xml] Schema
I will try to
go thru this bullet list the week after
Thanksgiving and update the document
accordingly.
Great start Dave!
-----Original Message-----
From:
Aaron Hansen
Sent: Tuesday, November 16, 2004 2:31 PM
To:
obix-xml@lists.oasis-open.org
Cc: Don.Delaurier@Edwards.spx.com;
ganesh.markale@honeywell.com;
Jeff.VanKeuren@Edwards.spx.com;
kirkatcaba@sympatico.ca
Subject: [obix-xml] Schema
A great big
thanks goes to Dave Richards of Trane for producing and taking
ownership of
the schema for the Sys service. He's done a great job!
Here
are some of his notes concerning the schema and
specification:
1) Section
2.5.1: Why disallow "0" and "1"? Seems easier to just
use
xs:boolean than to restrict it. I did not do the restriction in my
schema.
2) Section 2.6.8 should be called
"unit" to be consistent with element
name. Paragraph text should be
changed as well.
3) Section 2.6.8 - last
sentence should reference 2.7 rather than
2.6.
4) Section 3.2.6 - why is there a
service element with nothing but an
id element? Seems like we could
eliminate one or the other.
5) Section
4.2.2 - wasn't sure exactly what the ext element does or how
to accurately
represent the fact that the result can be an ext from other
namespaces.
I made it accept any element from another namespace, which is
not
right.
6) Section 4.2.2 - children
description should say "if the request..."
not "is the
request..."
7) Section 5.1.2 - can a write
element have both a value and an object
child? Seems like it
could. Also, why is there no analog of the
object/sub-object in the
read service to avoid repeating full
paths?
8) One issue with the schema
is whether we want all types explicitly
named or whether the anonymous types
are OK. Some WSDL importers seem to
have issues with nested anonymous
types.
9) For the read result, do we want
the generic <object> with the choice
of value elements or do we want to
create typed result objects? The typed
objects would allow us to
specify which facets are allowed for the various
types. They would also
allow a substitution group which is somewhat more
flexible than the choice
group.
Dave and I agree that the simple data types shouldn't be
top level elements.
Recommendations?
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]