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

 


Help: OASIS Mailing Lists Help | MarkMail Help

obix-comment message

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


Subject: oBIX v1.0 Comments


Comment (Section 4.16 Facets):
Based on what's written in section 3.6 Extendibility.  It's conceivable 
that there could be vendor specific facets so ...

A prescribed pattern for extending the set of facets that can be used to 
express object metadata is desired. Otherwise vendors might come up with 
conflicting patterns. This could be as simple as explicitly prescribing 
the use of XML namespaces to qualify vendor-specific facets.

Comment (Section 10.1.1 Read)
The requirement to always return an object's entire extent is certainly 
consistent with the REST philosophy, but in a practical sense, can be a 
large burden on a device.

A mechanism for filtering which sub-objects to return will probably be 
added as proprietary extensions by most vendors. 
Therefore, a standardized mechanism for specifying this filter is desired.

Comment (Section 10.1.2 Write)
The last sentence of the first paragraph implies that it is optional even 
to return the err object.  It's preferable that when Writes fail that the 
err object always is part of the response.  Suggest changing text to read 
"Servers must also return an err object to indicate the write was 
unsuccessful.

Comment (Section 10.2 Errors)
Would like a predefined error added for the indication that the server as 
aborted the request due to an error on a previous request within the BATCH 
operation.  Something like: ProcessingAbortedErr

Comment (Section 12 Watches)
Though oBIX does not want to require clients to implement web servers or 
expose IPs is it not true that in many M2M scenarios, the "client" machine 
will have a web server and known IP address (e.g., 2 oBIX-enabled servers 
from different vendors in different vertical markets, but in the same 
facility). I would think that in the future it could be desirable to have 
a standardized mechanism for watches when the server can push to the 
client.


David S. Eidson
Sr. Technical Lead
Metasys System Extended Architecture
Office Phone: 414-524-4267
Cell    Phone: 414-916-5714
Dave.Eidson@jci.com


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