<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 bgcolor="#ffffff" ocsi="x">
<div style="FONT-FAMILY: Tahoma; DIRECTION: ltr; COLOR: #000000; FONT-SIZE: 13px">
<div>Tim,</div>
<div><font size="2" face="tahoma"></font> </div>
<div><font size="2" face="tahoma">Your response confsuses me. First, define 'modification'? Are you saying for example,</font></div>
<div><font size="2" face="tahoma">iMesh_addEntToSet() where root set is used as the entity set handle to add a ent to</font></div>
<div><font size="2" face="tahoma">should return error? I assume you don't include iMesh_setEntSetIntData() in your</font></div>
<div><font size="2" face="tahoma">definition of 'modification', right? I mean that IS a modification but of tag data on</font></div>
<div><font size="2" face="tahoma">the ents/sets and not OF the ent/sets themselves?</font></div>
<div><font size="2" face="tahoma"></font> </div>
<div><font size="2" face="tahoma">What is the difference between calling iMesh_addEntToSet() where the same ent</font></div>
<div><font size="2" face="tahoma">is added to the same set as in a previous call and a call iMesh_createEnt followed</font></div>
<div><font size="2" face="tahoma">by iMesh_addEntToSet where the created entity is added to root? From a data model</font></div>
<div><font size="2" face="tahoma">perspective, these are totally analagous operations so they should at least be</font></div>
<div><font size="2" face="tahoma">consistent. In both cases, I am talking about redundantly adding an entity to a set.</font></div>
<div><font size="2" face="tahoma">In the first call, with multiple calls to the same method. In the second case with</font></div>
<div><font size="2" face="tahoma">two calls to different methods.</font></div>
<div><font size="2" face="tahoma"></font> </div>
<div><font size="2" face="tahoma">I think an addPrntChld where the parent entity set handle is root should no more</font></div>
<div><font size="2" face="tahoma">be an error than any other combination of entity set handles would be. In fact,</font></div>
<div><font size="2" face="tahoma">given that 'Prnt' and 'Chld' in these calls are really nothing more fundamental in</font></div>
<div><font size="2" face="tahoma">the data model than defining a UNdirected edge in a completely arbitrary, user-defined</font></div>
<div><font size="2" face="tahoma">graph, I am not even sure it would be an error to have the root set play the</font></div>
<div><font size="2" face="tahoma">role of a 'Chld' in the creation of an edge of the graph. The graph is arbitrary.</font></div>
<div><font size="2" face="tahoma"></font> </div>
<div><font size="2" face="tahoma">I think root set ought to be able to serve either role in the set operator calls,</font></div>
<div><font size="2" face="tahoma">unite, subtract and intersect too. Yes, intersecting one entity set with 'universe' may</font></div>
<div><font size="2" face="tahoma">be 'dumb' from a usage perspective but is a completely valid operation from a</font></div>
<div><font size="2" face="tahoma">data model perspective. Likewise for the other operations.</font></div>
<div><font size="2" face="tahoma"></font> </div>
<div><font size="2" face="tahoma">Below is my attempt to codify what I think correct behavior, from a data modeling</font></div>
<div><font size="2" face="tahoma">perspective, is....</font></div>
<div><font size="2" face="tahoma"></font> </div>
<div><font size="2" face="tahoma">iMesh_destroyEntSet in case of root set should 'return' iMesh_Instance to same</font></div>
<div><font size="2">s<font face="tahoma">tate as just after iMesh_newMesh(). Its almost an iMesh_dtor(). I see no model</font></font></div>
<div><font size="2" face="tahoma">level reason to disallow this on root set.</font></div>
<div><font size="2" face="tahoma"></font> </div>
<div><font size="2" face="tahoma">iMesh_isList on root set should return always '0' for is_list.</font></div>
<div><font size="2" face="tahoma"></font> </div>
<div><font size="2" face="tahoma">iMesh_addEntToSet on root set should behave identically as the second call in two</font></div>
<div><font size="2" face="tahoma">successive calls to </font><font size="2" face="tahoma">iMesh_addEntToSet with identical arguments where root is NOT</font></div>
<div><font size="2" face="tahoma">the set. In other words, adding an ent to root ought to mean the same thing as</font></div>
<div><font size="2" face="tahoma">adding the same ent to the same entity set. Is that an error? I don't know, but they</font></div>
<div><font size="2" face="tahoma">should be consistent.</font></div>
<div><font size="2" face="tahoma"></font> </div>
<div><font size="2" face="tahoma">iMesh_rmvEntFromSet on root set should behave same as iMesh_deleteEnt.</font></div>
<div><font size="2" face="tahoma"></font> </div>
<div><font size="2" face="tahoma">Likewise iMesh_addEntSet on root should behave identically as the second call in</font></div>
<div><font size="2" face="tahoma">two successive calls to iMesh_addEntSet with identical arguments. In other words,</font></div>
<div><font size="2">a<font face="tahoma">dding an ent set to root ought to mean the same thing as adding the same ent set</font></font></div>
<div><font size="2" face="tahoma">to the same ent set.</font></div>
<div><font size="2" face="tahoma"></font> </div>
<div><font size="2" face="tahoma">iMesh_rmvEntSet on root should behave same as iMesh_destroyEntSet.</font></div>
<div><font size="2" face="tahoma"></font> </div>
<div><font size="2" face="tahoma">I'll consider more later but this is how I see things with my 'data model' hat on.
</font><font size="2" face="tahoma">I'll</font></div>
<div><font size="2" face="tahoma">bet that in most if not all cases, I can make an argument that a given single call</font></div>
<div><font size="2" face="tahoma">to iMesh_<whatever> where root set is involved is analagous (at least in terms of the</font></div>
<div><font size="2" face="tahoma"><font face="tahoma">data model) </font>to one or more
</font><font size="2" face="tahoma">calls to other iMesh functions. If that winds up being true,</font></div>
<div><font size="2" face="tahoma">I would have difficulty a</font><font size="2" face="tahoma">ccepting implementation-level rationale for disallowing these</font></div>
<div><font size="2" face="tahoma">operations.</font></div>
<div><font size="2" face="tahoma"></font> </div>
<div><font size="2" face="tahoma">Mark</font></div>
<div><font size="2" face="tahoma"></font> </div>
<div><font size="2" face="tahoma"></font> </div>
<div><font size="2" face="tahoma"></font> </div>
<div style="DIRECTION: ltr" id="divRpF574070">
<hr tabindex="-1">
<font color="#000000" size="2" face="Tahoma"><b>From:</b> tautges@mcs.anl.gov [tautges@mcs.anl.gov]<br>
<b>Sent:</b> Friday, August 27, 2010 10:03 AM<br>
<b>To:</b> Mark Beall<br>
<b>Cc:</b> Miller, Mark C.; tstt-interface<br>
<b>Subject:</b> Re: Special-ness of root set: Impl. vs. data model<br>
</font><br>
</div>
<div></div>
<div>
<div>I think all modifications should return error, and probably all parent/child queries too. <br>
<br>
- tim
<div><br>
</div>
</div>
<div><br>
On Aug 27, 2010, at 11:03 AM, Mark Beall <<a href="mailto:mbeall@simmetrix.com">mbeall@simmetrix.com</a>> wrote:<br>
<br>
</div>
<div></div>
<blockquote type="cite">
<div>It certainly seems that the root set is special in some ways. I guess the question is, in which ways is it special?
<div><br>
</div>
<div>For example, calling iMesh_addEntToSet or iMesh_rmvEntFromSet on the root set doesn't make sense and should probably be an error, right?</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>mark</div>
<div><br>
<div>
<div>On Aug 27, 2010, at 11:45 AM, Miller, Mark C. wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite"><span class="Apple-style-span">
<div>
<div style="FONT-FAMILY: Tahoma; DIRECTION: ltr; COLOR: rgb(0,0,0); 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<span class="Apple-converted-space"> </span></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>
</div>
</span></blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
</div>
</body>
</html>