Special-ness of root set: Impl. vs. data model

[tautges at mcs.anl.gov]

I think all modifications should return error, and probably all parent/ 
child queries too.

- tim


On Aug 27, 2010, at 11:03 AM, Mark Beall <mbeall at simmetrix.com> wrote:

> It certainly seems that the root set is special in some ways. I  
> guess the question is, in which ways is it special?
>
> For example, calling iMesh_addEntToSet or iMesh_rmvEntFromSet on the  
> root set doesn't make sense and should probably be an error, right?
>
> So, clearly there are case where the root set is specified to behave  
> differently, but at the current time I doubt it's clear all the  
> cases that it should.
>
> mark
>
> On Aug 27, 2010, at 11:45 AM, Miller, Mark C. wrote:
>
>> Hi Folks,
>>
>> I am gaining some experience with the implementations that suggests  
>> that root set is
>> treated very differently than other sets. While I understand there  
>> are probably good
>> reasons from an implementation standpoint to do this, consider a  
>> very simple tool like
>> eyeMesh browser. What that tool basically does is traverse the set  
>> containment
>> hierarchy (the hierarchy defined by getEntSets() and then  
>> descending into each of those
>> sets). As eyeMesh traverses the hierarchy it gathers all the  
>> information it can regarding
>> each set; getNumTopo, getNumOfTopoType, isList, getNumPrnt,  
>> getNumChld, etc. eyeMesh
>> then presents this data in a textual oriented gui that allows you  
>> to browse what is there.
>>
>> It is coded using a simple recursion starting from the root set.  
>> Because of that, it queries
>> everything it ordinarily would, even on root set; isList,  
>> getNumPrnt for example. These calls
>> have shown to be problematic on a few implementations as no one  
>> expected to have to
>> implement them with the possibility that the given set might be the  
>> root set.
>>
>> In further investigating, I've learned that, for example,  
>> addPrntChld is not necessarily
>> expected to work with root set as well there might be other calls  
>> in iMesh that are
>> problematic to support on the root set.
>>
>> But, these are all impelementation issues and are not part of the  
>> data model. From the
>> point of view of the data model, the only thing that makes the root  
>> set 'special' is that
>> all other things are contained within it. It is effectively the  
>> 'universe' set. It cannot have
>> 'parents' or be 'contained in' another set.
>>
>> So, in my view, with my data model hat on and working only from the  
>> iMesh.h header
>> file (not from an implementation), I think that the root set ought  
>> to behave 'just like any
>> other set' and that there should be no implementation-driven  
>> restrictions upon its use
>> in the API other than those that can be derived directly from the  
>> data model. In particular,
>> implementations should be coded to operate 'reasonably' in all  
>> cases where an entity set
>> handle is required and caller passes root set for such. If the call  
>> does not make any sense
>> in the data model, then it is ok for the call to error out.  
>> However, if there is no legitimate
>> argument that the call does NOT make sense from the perspective of  
>> the data model
>> when 'entity set handle' is replaced with 'root set', then the call  
>> should return normally
>> and with reasonable results.
>>
>> If this is not consistent with others understanding of the data  
>> model and implementations,
>> please speak up loudly now so we can identify all the issues.
>>
>>
>> Mark
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/tstt-interface/attachments/20100827/fbf3de3b/attachment.htm>