iRel discussion:  Led by Seegyoung  8/24/10

P9: 
-  Need new functions (identified by Mark Beall):
   +  Remove classification of an object.
      -  Could we pass a NULL handle to iRel_setEntEntRelation to remove
         the classification?  Maybe.
   +  Change the classification of an object.
   +  Setting classification of an entity.
      -  Use iRel_setEntEntRelation
   +  Need to define how to reclassify an entity.
      -  Remove one relationship then add another?
      -  Important to do it in the right order, as some entities
         can be associated with only one entity.

-  Since classification and reverse classification have very specific
   rules, special functions that enforce the rules would be useful.
   +  For classification, an entity at level n can be classified to only
      one entity at level n+1.
   +  Nothing in spec says relations must be unique.

-  Decision:
   +  Use iRel_setEntEntRelation to set an initial relationship.
   +  Use iRel_setEntEntRelation to reset a relationship (removing old
      relationship, adding the new one).
   +  Use new function iRel_unsetEntEntRelation (or iRel_clearEntEntRelation)
      to remove a classification.

-  Action for Wednesday at 1pm (3pm EDT):
   +  Tim will propose iRel_unsetEntEntRelation.
   +  Tim will clarify the iRel_setEntEntRelation in iRel.h.
   +  Write a short code sample to show how people could use iRel interoperably.
      -  RPI will write one use case from classification.
      -  Tim will write one use case from DDrive for r-refinement.

-----------------------------------

P12:
Decision and Action:
-  Tim will change name of data type iRel_RelationHandle to iRel_PairHandle
   and review documentation to for needed changes.
-  Tim will send the OpenOffice document to Seegyoung for her additions.

-----------------------------------

P13:
Decision:
-  OK with adding iRel_getDescription.
-  Moving iterator type to iBase is OK.
-  Moving iterator functions to iBase is not OK; specific to the instance.
-  Name change iRel_newRel->iRel_create; iRel_dtor->iRel_destroy.
   Should be made consistent with other interfaces.
   (Previously agreed to changes to other interfaces 5/10; not yet implemented.)
-  Remove iRel_setSetSetArrRelation and iRel_setEntSetArrRelation.

Action:
-  Tim agrees to do all within two week..

-----------------------------------
P14:
-  What is iRel_inferAllRelationsAndType?
   Relation is already in implementation; service needs access to relation.
   iRel_PairHandle is an output parameter.
   But iRel_Instance does not know which mesh/geometry instances to return
   information about.
-  Tim says need a use case; not sure the current functions
   iRel_inferAllRelations and iRel_inferAllRelationsAndType will suffice
   for even his use case.

No Decision.

Action:
-  Tim will write the use case and circulate for comment.

-  Interface-specific error types:
   + INVALID_PART_HANDLE, INVALID_PARTITION_HANDLE in iMeshP.h
   + iRel_ErrorType in iRel.h
   + Need to make sure the numbers are unique across interfaces.
   + Keep the common types.

Decision:  
   +  Keep adding error types to iBase_ERROR_TYPE.
   +  Name them with the interface-specific name; e.g., 
      iMeshP_INVALID_PART_HANDLE is a value in enum iBase_ErrorType.

Action:
-  When new error type is needed, requestor will email the mailing list
   to discuss error type names and need.  If OK, requestor will add the
   error type.
-  Jason will propose an offset for the error type enumerations.
-  Misbah and Seegyoung will email specific suggestions for type they need now.