[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [obix-xml] Things I'd like to discuss at tomorrow's telecon.
> -----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?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]