iRel.h interface update [was iRel proposal: removing non-one-to-one relation functions]

[seol at scorec.rpi.edu]

> On Thu, 2010-10-28 at 03:12 -0400, seol at scorec.rpi.edu wrote:
>> 4. adding "EntArr" to "Relation Type" and removing iRel_getEntSetIter & iRel_getEntArrSetIterArr
>>
>>    CURRENT Relation Type: Ent, Set, Both (Ent&Set)
>>    NEW: Ent, Set, Both (Ent&Set), EntArr
>
> Assuming we end up agreeing that directly encoding one-to-many
> relationships in iRel (instead of relying on iMesh/iGeom to give us this
> though sets and/or iterators), I don't think this is a good way to go
> about doing it as it's really just a hack to work around implementations
> that don't support sets.

vice versa. supporting set-only relation type is not a good way either as it requires a hack to work around
implementation that don't use sets as a way of grouping of multiple data

> Don't take the above suggestion as endorsement, though. As the
> maintainer of (currently) the only iRel implementation, I should note
> that doing this (either your way or mine) will significantly increase
> the complexity and decrease the potential for interoperability** of iRel
> unless the iMesh and iGeom specs are updated as well.

It's not clear why not having EntArr relation type. Please describe the following.
  - how iRel, iMesh and iGeom should be updated further by having EntArr relation type.
  - why EntArr and Set are not othorgonal so iRel shouldn't have EntArr relation type losing the generality (limiting
its capability to support one-to-(set)many only).
  - why MOAB/Lasso cannot support EntArr relation type to account for FMDB-like implementation as we do support set
relation type to account for MOAB-like implementation in all other interfaces.

Seegyoung

> I've discussed some of these options before with Tim Tautges, and what
> you're proposing is not a small change by any means. It may require
> rethinking large portions of the iRel specification (e.g. asymmetry),
> which may not be entirely bad, as the draft specification is more than a
> bit sparse in some areas. (I'm sure people have ideas about how they
> think it should work, but it would be good to ensure we're all on the
> same page here.)
>
> ** Between different implementations of ITAPS interfaces
>
>> This avails non set-dominant impementation to support "iRel" effectively without interfering set-dominant
>> implementation and not against neither of "interchangeability" and "interoperability".
>
> I must confess that my knowledge of other ITAPS implementations is
> limited, but are you suggesting that a) you wouldn't support the
> set-based functions in iRel at all, or b) that you'd support them, but
> they wouldn't be the optimal way of working with data in your
> implementation?
>
> If we're talking about (a) here, this is a pretty optimistic view,
> perhaps overly so. Clearly, if one implementation supports a given
> function and the other does not (e.g. a "set-dominant" interface doesn't
> fully support arrays or an "array-dominant" interface doesn't support
> sets), that function is by definition not interchangeable. For
> MOAB/CGM/Lasso, this problem is academic, since MOAB and CGM support
> both set- and array-based operation (and Lasso will too, however it ends
> up looking), but for other implementations, this could be more serious
> issue. In practice, this would mean that you'd be unable to use many of
> the tools we write that target ITAPS interfaces.
>
> If we're talking about (b), see my discussion above on relation
> cardinality.
>
> - Jim
>
>