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.


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?

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?


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.

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]