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

[Mark Shephard]

On 11/1/10 8:35 AM, Tim Tautges wrote:
>
>
> On 10/28/2010 03:10 PM, Mark Shephard wrote:
>
>>
>> Considering that the iRel specification at this point came from one
>> place with in essence, no input for others that have implementations, it
>> is a reasonable thing to be careful and if we need to modify things so
>> relationships are support for all of ITAPS.
>>
>
> 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.

Your other email has lots of statements and assumptions that are not true.

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.

>
> - 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
>>>
>>
>>
>