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: Response to comments from Dave Eidson


David,
 
Thanks for taking the time to review the spec and for your thoughtful
comments.  Below I've attempted to address each one of your comments.  I
believe Toby will be scheduling a call to discuss the public review, at
which time we can go into detail about any of these responses.
 
> Comment (Section 4.16 Facets)
 
Good point - using namespace qualified attributes is exactly how we have
prototyped such things as BACnet specific indices into an oBIX document.
I added the following sentence to 4.16:  Vendors which wish to annotate
objects with additional facets should consider using XML namespace
qualified attributes.
 
> Comment (Section 10.1.1 Read)
 
The philosophy of extents is that only the server vendor understands the
best way to break up his data model into discrete networkable chunks.  A
general purpose client will never have the understanding necessary to
make the appropriate decisions about the depth of a read.  I would argue
that the need for a filtering sub-objects indicates the server vendor
didn't do a good enough job breaking up his data model into chunks, and
even if we had such a facility, a general purpose client wouldn't know
how to use it.  Also remember that server vendors are free to provide
hrefs to multiple levels within a extent - which effectively gives a
client the ability to read just a sub-tree of the extent which in
combination of batch reads is largely the same thing the filter you
describe.
 
> Comment (Section 10.1.2 Write)
 
I agree - the spec should more rigid.  
 
Old text:

"The server is free to completely or partially ignore the write, so
clients should be prepared to examine the response to check if the write
was successful.  Servers may also return an err object to indicate the
write was unsuccessful."

 

New text:  

"If the write is successful, the response must include the object's
complete extent (see 9.3).  If the write is unsuccessful, then the
server must return an err object indicating the failure."

 

> Comment (Section 10.2 Errors)

 

I can definitely see your point of view.  However, the way we designed
batches is that they work the same whether you batch or use individual
requests.  Under this scenario you are proposing a special error
contract which would break those semantics.  Furthermore I think most
server implementations would find it more difficult to implement with
marginal value to a client.

 

> Comment (Section 12 Watches)

 

That is definitely something we've talked about ever since day one.
With real-time point values, I think the existing one-way watches is
probably the right long term solution due to their robustness.  However,
there is definitely a gap in the current functionality for "pushing"
history data or alarms using oBIX.  Often times the network topology
requires a push solution (such as a device using dial-up to send an
alarm to a server on the Internet).  So I don't disagree that this
something we probably need to tackle eventually.  However the reason we
left it out of the 1.0 spec is that designing two-way messaging is a
step-change in the complexity.  Furthermore it seemed too early to
tackle this problem as other potential standards and best practices are
still evolving.

 
 
Brian
 

 



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