RE: [obix-xml] Issues

[Sam Yang <syang@echelon.com>]

I think points 1. and 2. are related.  I think any node in a path should be
able to represent the id of a point, and that therefore a point should be
able to contain other points.  We should be as generic as possible, and not
prevent that.

-----Original Message-----
From: Aaron Hansen [mailto:ahansen@tridium.com] 
Sent: Thursday, January 06, 2005 7:27 AM
To: Obix-Xml-Sc (E-mail)
Subject: [obix-xml] Issues


Well I've finally started implementing.  I haven't gotten very far, but here
are some shiny issues that caught my eye.


1. Containers vs. Objects

- We don't distinguish between containers and objects.  Currently it is
possible for a point to contain a point.  Is this common?  I'd rather see
the burden be on the vendor who has to decompose such constructs.


2. Pathing again

- After mentioning a commands service, I started thinking (for once)...  We
would have to develop a whole new model for complex arguments.  However, if
an object's id is it's leaf name then we could use the existing object
schema and even incorporate commands into Sys.  So I now support pathing and
changing read/write/subscribe to using paths instead of id's.


3. Polling

- Since we can't add/remove points from a subscription, the likely
implementation scenario will be a subscription for every container.  This
could lead to a client with many threads polling a server.  I would like to
see the pollReq allow multiple subscription id's.