Special-ness of root set: Impl. vs. data model
Miller, Mark C.
miller86 at llnl.gov
Fri Aug 27 10:45:52 CDT 2010
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/9076d9a9/attachment.htm>
More information about the tstt-interface
mailing list