Proposal for Requiring Save/Restore of Sets and Tags

[Carl Ollivier-Gooch]

On 10/04/2010 10:51 AM, Jason Kraftcheck wrote:
> On 10/01/2010 02:59 PM, Carl Ollivier-Gooch wrote:
>> On 09/29/2010 10:27 PM, Mark Miller wrote:
>
>>>
>>> In choosing a file format, there are several complicating factors to
>>> consider:
>>>     o Tags may be placed on entity sets as well as entities.
>>>     o Entity sets may contain entity sets as well as entities.
>>>     o The entity set containment graph may contain cycles.
>>>     o The entity set parent/child graph may contain cycles.
>>
>> I don't think it's particularly relevant to the way these things are
>> likely to be stored, but I strongly disagree, semantically, with
>> allowing cycles.  Also, it's harder to implement these the infinite
>> depth retrieval with cycles (not super hard, but harder).
>>
>> Containment can be interpreted as subset or member.  Subsets clearly
>> can't be cyclical (okay, you could have improper subsets in a cycle, but
>> why?).  Membership also doesn't make sense:  set A contains B contains C
>> contains A?  Draw me that Venn diagram!
>>
>> Parent-child semantics also don't make sense cyclically: A is the parent
>> of B is the parent of C is the parent of A?
>>
>> Finally, can anyone describe an actual use case for cycles?
>>
>
> IIRC, the last time the group discussed this, it was decided that we should
> allow cycles.  But even if we leave that as an implementation-defined
> behavior, it is not relevant to this particular discussion.  When storing
> iMesh data in a persistent format: if the implementation allows cycles then
> it should be prepared to save/load sets with cyclical relations.

I certainly agree that save/load should handle whatever is represented 
in the database, and I personally don't see it as difficult to save/load 
relationships that turn out to be cyclic, since you're likely to only 
store the first layer in the file anyway.

On the point of whether cycles should even be allowed:  The semantics 
that make sense in the set-theoretical sense don't include cycles, for 
membership, subsets, or heirarchical relationships.  Again, is there a 
plausible use case (with semantics that make sense)?  If not, then we 
should acknowledge this by saying so in the spec.  (And no, once again, 
I don't see it as a good idea to leave this implementation dependent.)

Carl

-- 
------------------------------------------------------------------------
Dr. Carl Ollivier-Gooch, P.Eng.                   Voice: +1-604-822-1854
Professor                                           Fax: +1-604-822-2403
Department of Mechanical Engineering             email: cfog at mech.ubc.ca
University of British Columbia              http://www.mech.ubc.ca/~cfog
Vancouver, BC  V6T 1Z4                  http://tetra.mech.ubc.ca/ANSLab/
------------------------------------------------------------------------