<html dir="ltr"><head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style id="owaTempEditStyle"></style><style title="owaParaStyle"><!--P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
--></style>
</head>
<body ocsi="x">
<div style="FONT-FAMILY: Tahoma; DIRECTION: ltr; COLOR: #000000; FONT-SIZE: 13px">
<div></div>
<div dir="ltr"><font color="#000000" size="2" face="Tahoma">Hi Folks,</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">I am gaining some experience with the implementations that suggests that root set is</font></div>
<div dir="ltr"><font size="2" face="tahoma">treated very differently than other sets. While I understand there are probably good</font></div>
<div dir="ltr"><font size="2" face="tahoma">reasons from an implementation standpoint to do this, consider a very simple tool like</font></div>
<div dir="ltr"><font size="2" face="tahoma">eyeMesh browser. What that tool basically does is traverse the set containment</font></div>
<div dir="ltr"><font size="2" face="tahoma">hierarchy (the hierarchy defined by getEntSets() and then descending into each of those</font></div>
<div dir="ltr"><font size="2" face="tahoma">sets). As eyeMesh traverses the hierarchy it gathers all the information it can regarding</font></div>
<div dir="ltr"><font size="2" face="tahoma">each set; getNumTopo, getNumOfTopoType, isList, getNumPrnt, getNumChld, etc. eyeMesh</font></div>
<div dir="ltr"><font size="2" face="tahoma">then presents this data in a textual oriented gui that allows you to browse what is there.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">It is coded using a simple recursion starting from the root set. Because of that, it queries</font></div>
<div dir="ltr"><font size="2" face="tahoma">everything it ordinarily would, even on root set; isList, getNumPrnt for example. These calls</font></div>
<div dir="ltr"><font size="2" face="tahoma">have shown to be problematic on a few implementations as no one expected to have to</font></div>
<div dir="ltr"><font size="2" face="tahoma">implement them with the possibility that the given set might be the root set.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">In further investigating, I've learned that, for example, addPrntChld is not necessarily</font></div>
<div dir="ltr"><font size="2">e<font face="tahoma">xpected to work with root set as well there might be other calls in iMesh that are</font></font></div>
<div dir="ltr"><font size="2" face="tahoma">problematic to support on the root set.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">But, these are all impelementation issues and are not part of the data model. From the</font></div>
<div dir="ltr"><font size="2" face="tahoma">point of view of the data model, the only thing that makes the root set 'special' is that</font></div>
<div dir="ltr"><font size="2" face="tahoma">all other things are contained within it. It is effectively the 'universe' set. It cannot have</font></div>
<div dir="ltr"><font size="2" face="tahoma">'parents' or be 'contained in' another set.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">So, in my view, with my data model hat on and working only from the iMesh.h header</font></div>
<div dir="ltr"><font size="2" face="tahoma">file (not from an implementation), I think that the root set ought to behave 'just like any</font></div>
<div dir="ltr"><font size="2" face="tahoma">other set' and that there should be no implementation-driven restrictions upon its use</font></div>
<div dir="ltr"><font size="2" face="tahoma">in the API other than </font><font size="2" face="tahoma">those that can be derived directly from the data model. In particular,</font></div>
<div dir="ltr"><font size="2" face="tahoma">implementations should be coded to operate 'reasonably' in all cases where an entity set</font></div>
<div dir="ltr"><font size="2" face="tahoma">handle is required and caller passes root set for such. If the call does not make any sense</font></div>
<div dir="ltr"><font size="2" face="tahoma">in the data model, then it is ok for the call to error out. However, if there is no legitimate</font></div>
<div dir="ltr"><font size="2" face="tahoma">argument that the call does NOT make sense from the perspective of the data model</font></div>
<div dir="ltr"><font size="2" face="tahoma">when 'entity set handle' is replaced with 'root set', then the call should return normally</font></div>
<div dir="ltr"><font size="2" face="tahoma">and with reasonable results.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">If this is not consistent with others understanding of the data model and implementations,</font></div>
<div dir="ltr"><font size="2" face="tahoma">please speak up loudly now so we can identify all the issues.</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
<div dir="ltr"><font size="2" face="tahoma">Mark</font></div>
<div dir="ltr"><font size="2" face="tahoma"></font> </div>
</div>
</body>
</html>