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

[Miller, Mark C.]

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?

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.

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mcs.anl.gov/pipermail/tstt-interface/attachments/20100827/cd78b212/attachment.htm>