OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

obix-xml message

[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.


Title: Message

I hope you can all easily read my comments below, in blue.

Sam

> -----Original Message-----
> From: Aaron Hansen [mailto:ahansen@tridium.com]
> Sent: Tuesday, February 22, 2005 6:54 PM
> To: Sam Yang
> Cc: obix-xml@lists.oasis-open.org
> Subject: Re: [obix-xml] Things I'd like to discuss at
> tomorrow's telecon.
>
>
> Sorry I wasn't clear, I meant the root object of the read or write
> operation, not the entire tree.
>
> I'm not against paths, but I think they might be an unnecessary
> complication.  The need is for every object to have a unique
> identifier,
> but I don't see any need for that identifier to be a path. 
> If we don't
> need to get into the issue of path seperator and escape character,
> wouldn't we be better off?

Without pathing, how does a client efficiently access a particular node anywhere in the hierarchy?  Using a path as the id value, you can get the exact object you want with a single depth-0 Read, giving a time complexity of O(1).  Without pathing, it seems to me the client must first discover the node (even though the client already knows the logical path to it), performing D-1 Reads (with a depth of 1, where D is the depth of the node), resulting in a complexity of O(D*N), where N is the average number of child nodes.

>
> I don't feel that strongly about handles, and I also get the feeling
> there could be something down the road that I'm not seeing which
> benefits from pathing.  Can anyone think of what that might be to cut
> short this discussion at the meeting?

What is the difference between a "handle" and an opaque id?

>
>
> As for depth, think about this:
>
> 1. Read object1, depth 1:
> <object1>
>     <object 1 metadata>
>     <children>
>        <object 2>
>           <object2 meta-data
>              <more children>
>
> 2. Read object2, depth 1:
> <object 2>
>     <object 2 metadata>
>     <children>
>        ...
>
> See, object 2 was completely re-read.  It is impossible to
> traverse the
> tree without completely re-reading entire objects.  I think
> most people
> will want to traverse oBIX trees using a depth of one, in which case
> they will read twice as much information than they need.  It just
> doesn't seem right to me.
>

In step 1, you could just ask for a minimal amount of data for object1's child nodes (maybe just their ids) and nothing else.  There is no need to get everything twice.  I can see, though, that just getting (opaque) child ids is not generally useful, because you'd usually want to know additional information about a child (like, its real non-opaque identity) before using the child node.  Therefore, you can't usually avoid getting some data twice.  This is another excellent argument for pathing.

> See you all at the meeting.
>
> Thanks,
> Aaron
>
>
> Sam Yang wrote:
>
> > > -----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
> > >
> > >
> > >
>



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]