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

[Mark Shephard]

Tim,

It appears that you want to just continue to drag this out and continue 
to point fingers.

The use case of classification and reverse classification are obvious 
and have been stated over and over again. Mark Miller already responded 
to other aspects of your email from this morning.

I still do not understand why it is not possible to let someone produce 
an iRel.h that works for all.

Mark


On 11/1/10 3:14 PM, Tim Tautges wrote:
>
>
> On 11/01/2010 07:48 AM, Mark Shephard wrote:
>
>>>
>>> To be fair, input was solicited many times, starting about year 2.5, and
>>> none showed up until about year 7.
>>
>> That is untrue. The importance of supporting classification and reverse
>> classification was discussed at the opening meeting of this project in
>> 2001. This well established requirement is used by many groups and has
>> always been important. Until there is an effective method to support it
>> we are still at the same point we have been at for a long time.
>>
>
> The point I was making was that there was no real attempt to implement
> the iRel interface as proposed in year 2.5 or so, that I recall, until
> about a year and a half ago.
>
>> Your other email has lots of statements and assumptions that are not
>> true.
>>
>
> Besides platitudes like this, can you point out specifics? I'm making an
> honest attempt to raise real issues here, and this "yes it did" "no it
> didn't" doesn't move us forward.
>
>> I do not understand why you will not allow the technical people to work
>> together to define a solution all implementations would accept? To be
>> more specific, at least twice there were solutions put on the table that
>> appeared to meet the needs of both sides only to have them not followed
>> through on in iRel.h. When iRel.h is such that you, Seegyoung and Mark
>> Beall feel things will work, we are set. Until then, we are where we
>> have always been.
>
> That's what I thought we had in January. So far, I haven't seen any
> information about somebody actually trying to implement it (besides Mark
> B's statement last week that that's what they were planning), nor a
> simple use case demonstrating where that solution falls short. In cases
> like this, where there are conflicting statements about whether the
> current proposal works or not for the important use cases, I'd think
> real use cases would help resolve those. I myself don't see much
> difficulty in coming up with use cases that reflect the various needs,
> but I think I shouldn't be the only one writing those.
>
> - tim
>
>>
>>>
>>> - tim
>>>
>>>>>
>>>>> ** 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?
>>>>
>>>> We support all the set functions. However, controlling everything by
>>>> sets becomes quite computationally intensive when you are doing lots of
>>>> local mesh modification, which is exactly what users of out
>>>> implementations are doing. Thus although we support sets, the
>>>> applications we support typically use sets in specific ways that cause
>>>> no complexity with the sets that are in place.
>>>>
>>>>>
>>>>> 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
>>>>>
>>>>
>>>>
>>>
>>
>>
>