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

[Mark Miller]

On Mon, 2010-08-30 at 19:59, Tim Tautges wrote:
> On 08/27/2010 02:37 PM, Miller, Mark C. wrote:
> >
> 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.

I am not sure where '...full generality...' is really coming in here.
The data model is the data model. The root set is a) a set and b) the
universe set. There is nothing I am doing/suggesting to 'generalize' the
data model. I am merely asking that the root set, since it is a set, be
allowed to be used as a set in ALL instances where a set is involved and
where it make sense at the data model level. I am asking for an
interpretation of the root set in the iMesh API that is 'free' from
implementation details.

> 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 'restricting' IS the problem. It introduces both complexity and
confusion. In the one case, I have the concept of an entity set of which
the root set is one such thing. In the other case, I have the concept of
an entity set and another concept, a root set, which is almost a set,
called a set, treated like a set, except in this case and that case and
the other case, etc., etc. That simply introduces complexity and
confusion where there is fundamentally none.

> I think doing things like making the root set a child of another set,
> contained in another set, or 

Correct me if I am wrong but in the 'Prnt' 'Chld' functions, there isn't
really ANYTHING that indicates what the relationship is between the
vertices at the ends of an edge in the graph. The letters 'P', 'r', 'n',
't' (which I guess is an abbreviation for 'Parent') and 'C', 'h', 'l',
'd' (which I guess is an abbreviation for 'Child') in the names of
various functions might be intended to suggest some kind of a
relationship. However, the actual data model that part of the interface
defines is an UNdirected graph where the vertices in the graph are
entity sets; nothing more. Now, maybe if you could tag the vertices
and/or edges of that graph you might argue that you can embue it with
some semantics.

'Parent' and 'Child' suggest a very specific kind of graph, a tree,
which I don't think the data model or specification makes any statement
of one way or the other.

Oh, and by the way, I argued for supporting things that are correct from
the point of view of the data model. So, that specifically does NOT
include having the root set 'contained in' another set.

> removing an entity from the root set yields results that are
> ambiguous, or at least of questionable integrity. 

Not if you treat the root set as the set it really is, the universe set.
Removing an entity from the root set is then the same thing as deleting
the entity.

> 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.

I can. The problem is writing code that uses the API when there are two
kinds of sets I have to worry about; entity sets and the 'almost an
entity set but not quite' root set. Working from a blind list of sets
which may or may not include the special root set, I now have to test
whether or not a given set is the root set before I pass it into
functions accepting sets and examine the error codes they return.

if (set != rooSet)
    iMesh_rmvEntFromSet()
else
    iMesh_deleteEnt()

or

iMesh_addEntToSet(...)
if (err != iBase_SUCCESS)
{
    if (set == root set)
        // its ok to fail cause its already in the root set
    else
        // its a real failure I should worry about.
}


-- 
Mark C. Miller, Lawrence Livermore National Laboratory
================!!LLNL BUSINESS ONLY!!================
miller86 at llnl.gov      urgent: miller86 at pager.llnl.gov
T:8-6 (925)-423-5901    M/W/Th:7-12,2-7 (530)-753-8511