Entity sets - containment and parent-child

[Jason Kraftcheck]

Mark Beall wrote:
> As the, fairly obvious, followup to my last email, since iRel already
> admits to the fact that there is a special relation between the mesh and
> the model (cf. iRel_createVtxAndAssociate, etc.) and has stated
> requirements on that relation (it must be between the geometry and mesh
> instance in that order), why not just create a special type of relation
> in iRel that represents that. For example:
> 
> void iRel_createGeomMeshAssociation(...,iBase_instance geom,
> iBase_instance mesh, ... options ..., iRel_GeomMeshHandle *rel);
> 

Tim and I have discussed having special creation functions before.  I think
it is a good idea for two reasons:  1) For some implementations, some types
of relations are handled in a special way and 2) The i*_instance handles are
unique types that do not implicitly cast to iBase_instance.  However, I do
not see why one would need a special type of relation handle.  That would
necessitate a lot of extra functions just to avoid abstracting things a bit
in the implementation.  I'd rather see the above function look like:


void iRel_createGeomMeshAssociation(...,iGeom_instance geom,
 iMesh_instance mesh, ... options ..., iRel_RelationHandle *rel);

> options here would say what directions you want the relation to support
> 

I don't strongly object to having such an option, but is it necessary?  Why
not just generate the relation links in the backwards (or forwards)
direction when they are first requested?


> void iRel_getGeomMeshAssociation(...,iRel_GeomMeshHandle rel,
> iBase_EntityHandle modelEnt, iBase_EntitySetHandle *meshEnts);
> 
> void iRel_getMeshGeomAssociation(..., iRel_GeomMeshHandle rel,
> iBase_EntityHandle meshEnt, iBase_EntityHandle *geomEnt);
> 
> maybe some other functions to create or release the relation in one
> direction or the other (possibly instead of the options on creation)
> 
> and the iRel_createVtxAndAssociate etc. functions take in a
> iRel_GeomMeshHandle
> 
> Discussion points:
> 
> - Yes, it's less generic, however it's already not generic in the
> interface, for iRel_createVtxAndAssociate to work, the relation has to
> be created in a certain way. This way it's enforced (rather than just
> documented).
> 

So we should duplicate every function in the interface for every possible
combination of interface types just to avoid one or two functions that could
potentially fail because they were passed the wrong type of relation?   This
would make the interface more type-safe but not, IMO, better considering the
added complexity.


> - If some application wants this relation, they want this relation, not
> something else.
> 

I don't get this.  If the application only wants one relation, why would it
have a handle to any other relation?

> - It avoids the discussion about whether or not it's necessary to be
> able to change a generic entity-set relation to an entity-both relation
> (or whatever) and gives the functionality for the case it's obviously
> needed.
> 

I haven't been following that discussion, so I'm probably missing something.
 I don't see how having a special type of relation for iMesh/iGeom provides
this any more seamlessly than providing it for any relation type.  It just
limits the functionality to one relation type.

> - Rather than figuring out how classification should be implemented
> (tags, entity-both relations) it's a generic expression of that relation
> that can be implemented in different ways.
> 

So is the current interface.  The use of tags is an implementation detail.
The use of entity->set relations is a data model question.  We could mandate
that all iGeom->iMesh relations are entity->entity with the current
interface as well.  We do not do so because one might have an implementation
that stores an entity->set relation to conserve space (does not explicitly
store classification for every entity.)  You solution of just removing that
implementation option a) may not be acceptable to all and b) doesn't require
any change to the interface.

- jason