RE: [obix-xml] Things I'd like to discuss at tomorrow's telecon.

[Sam Yang <syang@echelon.com>]

Title: Message

> -----Original Message-----
> From: Aaron Hansen [mailto:ahansen@tridium.com]
> Sent: Tuesday, February 22, 2005 7:46 AM
> To: obix-xml@lists.oasis-open.org
> Subject: [obix-xml] Things I'd like to discuss at tomorrow's telecon.
>
>
> Pathing
> ========
> - Isn't the need only to identify the root object for
> read/write operations? If so,
> - I don't think there is a need for pathing
> - I'm leaning towards an opague "handle" which is the unique
> identifier.

I don't understand this point.  Since the oBIX design assumes that every oBIX server exposes a node hierarchy of arbitrary depth, I don't see how you can avoid supporting the addressing of every node in the hierarchy (whether that addressing is opaque or not).  Maybe by "root" you mean something other than the "root object", as used in the draft spec?

Also, assuming that we will support addressing arbitrary nodes, how can a client efficiently read the state of a node that is, say, 15 levels below the root node?  In the current draft spec, it seems that the client would have to to perform 14 Read operations (each specifying a depth of 1) and look at some sort of identifying information in all the objects returned with each Read response to see which one is on the "path" to the desired node (or is the node itself).  (The client could instead make one call with a depth of 14, but that could result in an outlandishly large response).  Since the IDs used for all nodes are "opaque" (as a consequence of which the client has no idea how permanent the ID/node mapping is), the client should not even persist what it has learned about the hierarchy for use in a future session (on the other hand oBIX has no concept of a client "session", so maybe opaque IDs have to have permanent mappings to nodes?).

An easier approach would be to use a path that is composed of a string of IDs (maybe the same as the identifiers contained in the objects for each node along the path) separated from each other by a simple delimiter.  The state of the desired node can be obtained with a single Read request, and a developer/debugger might even be able to look at the requests and responses and figure out what nodes are being referenced.

>
>
> Misc notes
> =========
> - Should ObjectReadType be ObjectType?
> - Need default values for:
>     * DimensionType -> everything
>     * FacetsType -> resolution, precision, writable
>     * AlarmType -> inAlarm
>     * ReadReqType -> locale, depth
> - How about ext element in IncludeType be a boolean?  Think
> it would be
> much easier.
> - Shouldn't facets have trueText and falseText?
> - Units: I still don't like unit refs.
>     * We don't have unit read operation.
>     * Which object holds the master unit?  What if the client hasn't
> read it yet?
>     * Id should be a unique unit identifier, the client can
> table on that.
> - What is root?

The root could just be a special container for the real nodes (like the DOM Document Node is a container for the Document Element).  The root node is already defined to have an empty ID, so it is already not like a "real" node.

> - If read depth is 0, should more children be indicated?

As I recall, we decided "yes".

> - How about an object version?  If used, this could be used
> to indicate
> an object's facets have changed.
>
> I don't like depth
> =============
> - We'll end up double reading most objects during discovery
> (especially
> if everyone uses depth 1 as I feel they will).  Think about it.
> - In my tests, a depth a 5 resulted in a massively large
> document.  This
> feature is dangerous.
> - I think read should simply list children handles.

 

I don't think we should eliminate depth and simply enumerate all child IDs -- that would make Reads too verbose in a lot of cases.  I had brought up the "dangerousnous" of large depth before, but I though there was a feeling among the other members that "we are dealing with enterprise servers and clients, and they can handle anything".  That's why we didn't provide a way to get a child count, as I had wanted.  I think that we should leave depth the way it is (or at most limit its value range to [0..1]).

>
> Thanks,
> Aaron
>
>
>