RE: [obix-xml] Draft document 0.3

Title: Draft document 0.3

Doug,

 

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

  
-----Original Message-----
From: Doug Ransom 
  [mailto:]
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: 
Website: 
  http://www.pwrm.com 
  
ION®  
  smart energy everywhere™