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

[Tim Tautges]

On 08/27/2010 02:37 PM, Miller, Mark C. wrote:
> Tim,
> Your response confsuses me. First, define 'modification'? Are you saying
> for example,
> iMesh_addEntToSet() where root set is used as the entity set handle to
> add a ent to
> should return error? I assume you don't include iMesh_setEntSetIntData()
> in your
> definition of 'modification', right? I mean that IS a modification but
> of tag data on
> the ents/sets and not OF the ent/sets themselves?

Correct, I did not include tag functions in my definition of modification of the root set.  That is, we explictly 
support tagging of the root set.

> What is the difference between calling iMesh_addEntToSet() where the
> same ent
> is added to the same set as in a previous call and a call
> iMesh_createEnt followed
> by iMesh_addEntToSet where the created entity is added to root? From a
> data model
> perspective, these are totally analagous operations so they should at
> least be
> consistent. In both cases, I am talking about redundantly adding an
> entity to a set.
> In the first call, with multiple calls to the same method. In the second
> case with
> two calls to different methods.
> I think an addPrntChld where the parent entity set handle is root should
> no more
> be an error than any other combination of entity set handles would be.
> In fact,
> given that 'Prnt' and 'Chld' in these calls are really nothing more
> fundamental in
> the data model than defining a UNdirected edge in a completely
> arbitrary, user-defined
> graph, I am not even sure it would be an error to have the root set play the
> role of a 'Chld' in the creation of an edge of the graph. The graph is
> arbitrary.
> I think root set ought to be able to serve either role in the set
> operator calls,
> unite, subtract and intersect too. Yes, intersecting one entity set with
> 'universe' may
> be 'dumb' from a usage perspective but is a completely valid operation
> from a
> data model perspective. Likewise for the other operations.

I think this is a case where full generality of the data model conflicts with usability of the interface, where here I 
define that as restricting what you can do with/on the root set.  We use the concept of a root set to allow us to 
overload the set query and tag functions; I think restricting the functionality on the root set clarifies the interface 
and data model.  I think doing things like making the root set a child of another set, contained in another set, or 
removing an entity from the root set yields results that are ambiguous, or at least of questionable integrity.  Aside 
from tagging, I have trouble coming up with a believable use case for supporting more general functionality on the root 
set, or for where an application is likely to be confused by not having that.

While in general I like the idea of a fully general data model, I think in this case restricting the functionality of 
the root set is probably much less confusing for applications, at a very small if any practical reduction in generality.

- tim

> Below is my attempt to codify what I think correct behavior, from a data
> modeling
> perspective, is....
> iMesh_destroyEntSet in case of root set should 'return' iMesh_Instance
> to same
> state as just after iMesh_newMesh(). Its almost an iMesh_dtor(). I see
> no model
> level reason to disallow this on root set.
> iMesh_isList on root set should return always '0' for is_list.
> iMesh_addEntToSet on root set should behave identically as the second
> call in two
> successive calls to iMesh_addEntToSet with identical arguments where
> root is NOT
> the set. In other words, adding an ent to root ought to mean the same
> thing as
> adding the same ent to the same entity set. Is that an error? I don't
> know, but they
> should be consistent.
> iMesh_rmvEntFromSet on root set should behave same as iMesh_deleteEnt.
> Likewise iMesh_addEntSet on root should behave identically as the second
> call in
> two successive calls to iMesh_addEntSet with identical arguments. In
> other words,
> adding an ent set to root ought to mean the same thing as adding the
> same ent set
> to the same ent set.
> iMesh_rmvEntSet on root should behave same as iMesh_destroyEntSet.
> I'll consider more later but this is how I see things with my 'data
> model' hat on. I'll
> bet that in most if not all cases, I can make an argument that a given
> single call
> to iMesh_<whatever> where root set is involved is analagous (at least in
> terms of the
> data model) to one or more calls to other iMesh functions. If that winds
> up being true,
> I would have difficulty accepting implementation-level rationale for
> disallowing these
> operations.
> Mark
> ------------------------------------------------------------------------
> *From:* tautges at mcs.anl.gov [tautges at mcs.anl.gov]
> *Sent:* Friday, August 27, 2010 10:03 AM
> *To:* Mark Beall
> *Cc:* Miller, Mark C.; tstt-interface
> *Subject:* Re: Special-ness of root set: Impl. vs. data model
>
> 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
> <mailto: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
>>

-- 
================================================================
"You will keep in perfect peace him whose mind is
   steadfast, because he trusts in you."               Isaiah 26:3

              Tim Tautges            Argonne National Laboratory
          (tautges at mcs.anl.gov)      (telecommuting from UW-Madison)
          phone: (608) 263-8485      1500 Engineering Dr.
            fax: (608) 263-4499      Madison, WI 53706