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

[seol at scorec.rpi.edu]

>
> You're talking about hacks to an implementation. I mean hacks to the
> interface; the EntArr proposal seems to be operating under the premise
> that we shouldn't change any of the other parts of iRel to help you guys
> out, so you have to "bolt on" a new feature. Really, the current way
> isn't good for you guys, but EntArr doesn't help us in any way. We'd end
> up with two parallel interfaces that the "other guys" would have no use
> for except as a compatibility layer.
>

As long as you have "EntArr==Set" concept in mind which is not in none of other itaps interface, you are not making
any contribution to this itaps project. I strongly recommend to look at iMesh/iGeom spec before you propose
"inconsistent iRel spec change". As far as remember, you proposed iRel change twice which is not very much related to
the existing itaps interfaces.
  - one is about removing all non-one-to-one functions where we are not even set with classification support issue.
  - the other is having three Relation Types {ENT,ENTARR,SET} and four cardinality {one-one, one-many, many-one,
many-many} which results in total sixteen combinations although you don't know how they are useful.

Tell me what are "useless two parallel interfaces" you ended up due to "OTHER GUYS".
I am planning to work on "iMeshP" as soon as iRel is consolidated and I will look at that part.

Seegyoung

> The problem here is that iRel obviously needs to support a one-to-many
> relation *somehow*, and currently, it tries to do this by piggybacking
> on sets from iMesh/iGeom. That's what the "Set" relation type is.
> Obviously this is bad for implementations that don't use sets, but I
> think it's bad in general. It makes the implementation less clear, and
> if we want to support one-to-many relations (without deferring
> *completely* to iMesh/iGeom sets), we should commit to that instead of
> doing it partway (EntArr doesn't help one-to-many-sets, for instance).
>
> Besides, there's no logical difference between "RelationType = {Ent,
> Set, EntArr, SetArr}" and "RelationType = {Ent, Set}, CardinalityType =
> {One, Many}"*, but the latter way pushes iRel closer to "traditional"
> relational DBs, which can only be a good thing, if for no other reason
> than that it's easier to write documentation for.
>
> * I'm ignoring Both for now, just for simplicity.
>
>> > 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.
>
> Again, I'm not saying that something equivalent to "EntArr" is bad, but
> that calling it that is limiting to us (there's no "SetArr"). Pulling it
> out into a "cardinality" flag does the same thing but reads better.
>
> However, either EntArr or my cardinality alternative would require us to
> significantly change how our iRel implementation works. If we stick with
> represent "many" as just a set, then we have to add a lot of extra logic
> to handle creating a one-to-many relation that isn't already backed by a
> set. The code for EntEntArr relations is already fairly brittle in
> Lasso, and I'd rather it not get worse.
>
> The "clean" alternative is to store the "many" directly on a tag, but
> that would mean we need variable-length tags in iMesh/iGeom or we have
> to fall back to MOAB's native interface, which would make it more
> difficult to use Lasso with any other implementation (or to port it
> over).
>
>>   - 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).
>
> I'm not sure what exactly you mean by this, but if two things are
> orthogonal, as you seem to be suggesting, I think it makes sense for
> them to be represented as different parameters.
>
>>   - 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.
>
> I haven't said that we can't do this, only that it makes things
> significantly more complicated for us. As I already mentioned, my
> alternative doesn't actually make things any simpler for us, it just
> makes the interface clearer.
>
> - Jim
>
>