[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Response to comments to be included into 1.1.1 draft
The following is a list of comments and questions which Dave collected. I've written a response to each or noted that I've made a fix in the upcoming 1.1.1 draft document. 1) abstime contract has zone information missing in val facet. [actually there was a much bigger problem pointed out by Craig that XML Schema requires dateTime values to include the seconds - I went through all the abstime examples and added both seconds and a "Z" zone id] ------------------------- 2) Align batch and watch concept with each other. E,g, ending "/" is not accepted in WatchIn. We want to make same convention for the batch. Considering BatchOut is an ordered list, we can make the statment "Request and responses in batch shall be matched by order (not uri)". [I'm not sure these concepts can or should be aligned. Batch is a linear sequence of operations which may or may not use unique URIs. A watch is a modifiable "set" of URIs to watch - given that URIs can be added/removed/polled in any order, I don't think order position is really a valid candidate for keying (which is why we require keying on a URI). In both cases (batch and watch) we have at times past discussed using another identifier attribute for matching requests/responses - but it never has gained much traction. ------------------------- 3) Request for review of unit contracts. e.g. we believe that obix:units/cubic_feet_per_minute has incorrect scale. [Looking at http://en.wikipedia.org/wiki/Cubic_feet_per_minute is says that 1 CFM is 0.471947443 Liter per second (l/s) and a liter/sec is 0.001 m3/s, so doesn't that make CFM scale 4.719474432E-4?] ------------------------- 4) oBIX need to have some sort of choice contract like the choice data type BACnet has. [discussed in last meeting, no compelling use cases] ------------------------- 5) obix:ref shall not be used to define contracts (top level). obix:ref is special, "is" facet does not represent inheritance / implementation. [I'm not sure what this means or what it is referring to - section numbers would help] ------------------------- 6) obix:enum contract definition is conflicting. It has both val="" (empty string) and null="true". Section 4.6 states that enum are null by default. Contract inheritance section 6.1 and 4.6 looks conflicting to me. [I don't see the conflict - the enum value does default null to true, the fact that it defaults val to the empty string is secondary (that simply defines what val would be if you un-nulled an enum without providing a val] ------------------------- 7) If possible make a clear distinction between contract and instance. - I am sure this will not be acceptable. Looks like they (oBIX) want to keep the dynamic nature of oBIX intact. [this is by design and the core principle of prototype inheritance] ------------------------- 8) In the Quick Start section, the "unit" facet is shown as "units". [actually this mistake was repeated in a couple of places - fixed now] ------------------------- 9) The Object Model diagram is a little misleading since it looks as though the writable facet applies to things that are never writable. [technically I think you can apply writable to whatever you want assuming you are going to let clients write it - so the diagram is correct] ------------------------- 10) The contract definition for int is missing the equals sign after "val". [fixed] ------------------------- 11) "It" should be changed to "It's" in the second sentence of section that describes the ref object. [fixed] ------------------------- 12) The section titled Contract Compatibility ends with "any take away" instead of "take any away". [fixed] ------------------------- 14) The section titled "Namespace Prefixes in Contract Lists" mistakenly uses "it's" instead of "its". This may be true in other places as well. [fixed] ------------------------- 15) In the section titled Operations, the second to last paragraph says "In this case use set". [fixed] ------------------------- 16) The section titled "Range" says "an bool" instead of "a bool". [fixed] ------------------------- 17) Section "Alarm States" says "This variables" instead of "This variable". [fixed] ------------------------- 18) Here are some excerpts from the oBix spec that deal with not passing values that equal the contract defaults: * Defaults: contracts also provide a convenient mechanism to specify default values. For example the Alarm contract provides a specification for all the default values which don't need to be passed over the network for every read. A contract's named children objects are automatically applied to implementations. An implementation may choose to override or default each of its contract's children. If the implementation omits the child, then it is assumed to default to the contract's value. If the implementation declares the child (by name), then it is overridden and the implementation's value should be used. And here are some excerpts that talk about returning the full extent of objects: An object's extent is its tree of children down to references. When marshaling objects into an XML, it is required that an extent always be fully inlined into the XML document. The only valid objects which may be referenced outside the document are ref element themselves. If the object implements a contract, then it is required that the extent defined by the contract be fully inlined into the document (unless the contract itself defined a child as a ref element). The read request specifies an object's URI and the read response returns the current state of the object as an oBIX document. The response must include the object's complete extent (see 9.3). Is there a conflict here? How can children that equal the contract default be excluded from a read response if the response is to include the object's complete extent? [Originally we were going to allow defaults to be used in network processing, however eventually we decided to against it (in order to avoid the post-schema-validation-infoset problem that occurs when you require the XML Schema to be known to get attribute defaults). I changed that bullet in chapter 6 to be: Defaults: contracts also provide a convenient mechanism to specify default values. Note that when serializing object trees to XML (especially over a network), we typically don't allow defaults to be used in order to keep client processing simple]. ------------------------- 19) Here's another excerpt from the oBix spec: Only the val attribute should be specified for a write request (outside of identification attributes such as name). A write operation that provides facets has unspecified behavior. Isn't this saying that clients are not allowed to write >null="true"<? The Evox Guidelines document says clients can set objects to null. Does this break the oBix rules or is it just one way evox bends them? If clients aren't supposed to write null values, how are we going to allow them to release control? Are we going to end up using an operation of some sort? [The intention is that clients can write null - the following sentences are added to the spec: The null attribute may also be used to set an object to null. If the null attribute is not specified and the val attribute is specified, then it is implied that null is false.]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]