[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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 :
I suggest that the SysService use cases have not been elaborated sufficiently in section 3 to evaluate the material of 3.1 and on.
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
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.
Do the facets have anything to do with XML Schema facets?
Should all ids should be URIs?
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?
Should we seperate the service from the data model, define a data model the service queries, then define the service?
Energy Analytics Domain Expert
2195 Keating Cross Road
Saanichton, BC, Canada V8M 2A5
Tel: (250) 652-7100 ext. 7558
Fax: (250) 652-0411
ION® smart energy everywhere™