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

[Carl Ollivier-Gooch]

On 08/27/2010 09: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,

Thanks for volunteering to do an audit of all set-related functions and 
propose the proper behavior of  these when passed a root set. ;-) Then 
we'll all argue with whatever results you come up with.

Carl

-- 
------------------------------------------------------------------------
Dr. Carl Ollivier-Gooch, P.Eng.                   Voice: +1-604-822-1854
Professor                                           Fax: +1-604-822-2403
Department of Mechanical Engineering             email: cfog at mech.ubc.ca
University of British Columbia              http://www.mech.ubc.ca/~cfog
Vancouver, BC  V6T 1Z4                  http://tetra.mech.ubc.ca/ANSLab/
------------------------------------------------------------------------