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

 


Help: OASIS Mailing Lists Help | MarkMail Help

obix-xml message

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


Subject: RE: [obix-xml] Schema


Title: Message

In going over the schema and the spec, I have, as it turns out, quite a few comments.  Some of my comments are interleaved in the appended messages, and some are up here.

 

1.    Why do we need both <param> and <ext> for extensions? We should try to use just one.

2.    Why do we need special error elements (<error> for read and write responses, and <invalid> for poll responses), when we already have <status>, which seems perfectly adequate? We should try to reuse elements we already have.

3.    I think we need to have, in the schema, a base type for requests and another one for responses. For instance, all requests should have an optional <locale> element, and all responses should have an optional <status> element. For instance:

 

<xs:complexType name="BaseRequestType">

<xs:sequence>

<xs:element name="locale" type="xs:language" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

 

  <xs:complexType name="BaseResponseType">

<xs:sequence>

<xs:element name="status" type="tns:StatusType" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

 

 

Then, for instance, the <ReadReqType> would look like:

 

<xs:complexType name="ReadReqType">

<xs:complexContent>

<xs:extension base="BaseRequestType">

<xs:sequence>

<xs:element name="depth" type="xs:int" default="0"/>

<xs:element name="include" type="tns:IncludeType"/>

<xs:element name="id" type="xs:string" maxOccurs="unbounded"/>

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

 

4.    We need more work on using references versus values (as in the <range> and <unit> elements). We want the XML Schema to make the two approaches mutually exclusive. The current schema does not do that. One easy way to do this is to have a different element for the references. For instance, adding a <rangeRef> that only has an id attribute, and taking that attribute out of <range>. There are other ways of doing this as well.

5.    In <status>, the functionality seems broken. What if inAlarm is true, but unacked is for a past alarm? Also, what if there are multiple alarms going off at the same time? Should we have multiple alarms in status, each with its own <display>, <timestamp>, and <param> elements?

6.    In a write request with multiple <write> elements, is the server required to do the writes in the order presented? Simultaneously? In any order desired? I think the first choice must be dictated by the spec. Also, when a write fails, should the write request immediate fail and respond with the status, or should it continue on to the remaining <write> elements? I think it should immediately stop and return status.

7.    There is a problem with the subscription model. The poll response is only supposed to contain data that has changed since the last poll request. But a poll request can override the <include> filters as well. So, it will be very confusing as to what to expect back when you keep changing the <include> in a poll request. Maybe on the server we should make the <include> in the poll request replace the <include> in the original subscribe request. Also, what happens when a response is missed? The client could then lose data changes. To help the client resync, the request should have a way to ask for all the data instead of just what has changed.

 

-----Original Message-----
From: Brian Frank [mailto:bfrank@tridium.com]
Sent:
Tuesday, November 30, 2004 7:51 AM
To: Jeremy Roberts; obix-xml@lists.oasis-open.org
Cc: Don.Delaurier@Edwards.spx.com; ganesh.markale@honeywell.com; Jeff.VanKeuren@Edwards.spx.com; kirkatcaba@sympatico.ca; Aaron Hansen
Subject: RE: [obix-xml] Schema

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. 

[Sam] <display>, at least, should be totally unrestricted, since it can legitimately contain CR/LF and tabs, and sequences of more than 2 blanks.


---

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

[Sam] How about renaming <services> to <serviceIdList> and making it a simple list of URIs, as shown below? The spec would also have to say that a service ID must be a URI, instead of saying it should be, but I think that should not be a big deal.

 

<xs:element name="serviceIdList">

<xs:simpleType>

<xs:list itemType="xs:anyURI"/>

</xs:simpleType>

</xs:element>

 

We can do the same kind of thing with <locales> <localeList>, also shown. The renaming is not only for clarity, but also makes it trivial to differentiate visually between "locale/"locales" and "service"/"services".

 

<xs:element name="localeList">

<xs:simpleType>

<xs:list itemType="xs:language"/>

</xs:simpleType>

</xs:element>

 

This simplifies the schema a little, and allows the instance documents to be smaller as well.

 

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.

 

[Sam] I guess we could open it allow to any element, even from the same namespace, since we should allow maximum flexibility for extended data. For instance, some service might want to embed the original request or some part of it in its response to that request.

 

 

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]