RE: [obix-xml] Draft document 0.3

["Brian Frank" <bfrank@tridium.com>]

Title: Draft document 0.3

Doug,

 

Those are some good comments.  Some quick replies to specifics...

-----Original Message-----
From: Doug Ransom [mailto:Doug.Ransom@pwrm.com]
Sent: Tuesday, August 31, 2004 12:37 PM
To: OBIX XML
Subject: [obix-xml] Draft document 0.3

I think it is great there is some energy in this group.  I took a brief look at the proposal we have discussed here and wanted to toss some things out before the meeting :

http://www.oasis-open.org/apps/org/workgroup/obix-xml/download.php/8995/wd-obix-0.3.doc

I suggest that the SysService use cases have not been elaborated sufficiently in section 3 to evaluate the material of 3.1 and on. 
[Brian Frank] The intention is to use this document as a working draft for the technical work.  "Filler" materials will be added last once all the nuts and bolts are worked out.  Although it is a good idea to continually validate the technical solution against the use cases.   

Here are some example use cases:

Get the status of all the fans in the hvac system.
Get the history of all the fans status.
Get the lighting systems status
Get the all dates nighting building access
Put the lighting system in conservation mode for 90 minutes
Discover the objects of interest, take the specs home, code and test against mock objects in the office, then deploy in the field.

Get the history of the lighting system.  This might take 5 years.

Find the obix-compatible systems within the enterprise
[Brian Frank] I believe this to be outside the scope of oBIX.  It is better addressed by other standards such as UPnP. 

Report on hvac system and security system histories.  It might take 20 minutes to get a response.

I will attempt to comment on sections 3.1 and on.

<readReq> and <readResp> looks like messages.  Are these going to be soap services (i.e. specified in wsdl?).  In that case, do we need these elements at all?  They would be part of the soap stuff and not the payload.
[Brian Frank] We will probably create many different kind of transport bindings.  In any case I think all requests, responses, and events should be defined as a single XML element type for simplicity.

Do the facets have anything to do with XML Schema facets? 
[Brian Frank] I just choose the term facets to describe runtime meta-data.  In many cases they provide similar semantics as XML Schema facets, except more loosely typed and at runtime. 

Should all ids should be URIs?
[Brian Frank] Ids are a rather complicated topic which I haven't addressed explicitly.  Although my original proposal goes into pretty gory details.  Basically I think they should be opaque strings. 

Can xpath, xquery, or xslt be leveraged to replace some of the methods of the service?  Why not send an xpath as a service argument?  I could see this easily replacing the include element?

[Brian Frank] I am not sure how that would simplify or benefit the spec.  Unless there is an overwhelming reason, I'd rather leave the very long list of XML and WS heavy weight technologies out of the core oBIX spec, but co-exist gracefully.

Should we seperate the service from the data model, define a data model the service queries, then define the service?  

[Brian Frank] I think each service defines it's own domain specific data model.  However, I envision types like the simples, facets, range,  and unit being shared across multiple services as normalized types.

Doug Ransom
Energy Analytics Domain Expert
Power Measurement
2195 Keating Cross Road
Saanichton, BC, Canada  V8M 2A5
Tel: (250) 652-7100  ext. 7558
Fax: (250) 652-0411
E-Mail: mailto:doug.ransom@pwrm.com
Website: http://www.pwrm.com
 
ION®  smart energy everywhere™