Proposal for Requiring Save/Restore of Sets and Tags

[Mark Miller]

Hi Carl,

I don't think I disagree with anything you've said.

But, if the spec. says cycles are NOT allowed and an implementation
supports that, I don't see how that is a problem.

So, maybe the whole issue is mentioning the issue of cycles as
prominently as they are in the proposal.

Now, if the spec. says cycles ARE ALLOWED and an implementation does NOT
support that, then that would be a problem.

But, I think you are arguing that the spec. should NOT include cycles. I
kinda agree with that as they really don't seem to make sense. The only
use case I can think of is improper subsets where some implementation
wants to be a little lazy about detecting outright equality between
subsets where it might otherwise easily decide its ok to make one a
subset of another.

Mark



On Mon, 2010-10-04 at 11:33, Carl Ollivier-Gooch wrote:
> 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
-- 
Mark C. Miller, Lawrence Livermore National Laboratory
================!!LLNL BUSINESS ONLY!!================
miller86 at llnl.gov      urgent: miller86 at pager.llnl.gov
T:8-6 (925)-423-5901    M/W/Th:7-12,2-7 (530)-753-8511