Re: MV Keys (was: Key attributes with list values)

David Cressey wrote:
> "dawn" <dawnwolthuis_at_gmail.com> wrote in
>
>
> > Marshall Spight wrote:
> > > David Cressey wrote:
> > > >
> > > > The way Pick (and I presume most of the MV family) represent lists is
> > > > inherently ordered. And, whenever I ask Dawn, or any of the other
> Pickies
> > > > who dorp in form time to time whether the order in a list conveys
> > > > information or not, the answer is always the same:
> > > > "the programmer knows what the data means".
> >
> > I might have said it that way, but the way I would typically say it is
> > that the user knows what it means.
>
> This answers that question. But it raises another: how does a user share
> data with another user who may not (yet) know what the data means?

I agree that this seems like a problem and I'm sure the must be times when data are entered as unordered in their meaning and then when presented as a list, they are interpreted as ordered. Additionally, one end-user could maintain a list ordered in some way they perceive, while the next person to maintain that list might be unaware of an ordering and simply place new entries at the top or bottom of the list.

For what it is worth, I do not recall any such misunderstandings in working with Pick since '89. This might be due to poor recollections or to such misunderstandings requiring no escalations of such issues.

But I do agree, in concept, that knowing whether one is working with a list, bag, or set would be best. But I think I also agree with Marshall that sets and lists are sufficient. That means that conceptual bags will be implemented as lists, which puts us into the situation of not knowing. From a practical standpoint, I'm satisfied with sets at the top level and nested lists, skipping nested sets (relation-valued attributes). --dawn Received on Mon Feb 27 2006 - 15:35:14 CET