RE: [xtm-wg] Nikita's comments

[Daniel Rivers-Moore <daniel.rivers-moore@rivcom.com>]

The intent (I thought) was that it was indeed an error (in a Consistent
Topic Map) for there to be two members in the same association with the same
role, but that each topicRef within the member references a topic that is a
player of that role. Nothing needs to be reified specially, since the
topicRefs already point at topics which are the role players. If two of the
topics referenced by topicRef children of the same member happen to have the
same subject, they will be merged. But if the topics referenced have
distinct subjects, then the players remain clearly separate, despite being
involved in the association through the same 'member' element.

In the family association, this means that any number of topics can be
players of the brother role. There will be one member element whose roleSpec
subelement references the topic "brother", and as many topicRef children of
the member element as are needed to point to all the brothers in the family.

I don't see where the difficulty lies. Have I missed something?

Daniel

-----Original Message-----
From: Lars Marius Garshol [mailto:larsga@garshol.priv.no]
Sent: 09 February 2001 10:43
To: xtm-wg@yahoogroups.com
Subject: Re: [xtm-wg] Nikita's comments



* Nikita Ogievetsky
| 
| You are right, F.3.3 is dangerous.
|
| It allows processing software to "unite" members with the same role
| even if they have -id- on them and may be are reified somewhere else
| in the document.
 
You are quite right about this.  It is one of the issues with the
current association structure that we came across when implementing
this.  It is of course possible to retain the ID, but if you do so you
lose the information about which of the players the ID originally
applied to.

There is a trade-off here, however, since to allow associations in
in-memory structures to contain multiple 'member' objects with the
same role is awkward for applications.

I see three alternatives:

 - leave the spec as it is, gain ease of use, but allow applications
   to shoot themselves in the foot in some rare cases

 - take F.3.3 out and lose ease of use, but make XTM safer

 - take F.3.3 out, but insert a statement to the effect that it is a
   reportable error for two members in the same association to have
   the same role.  

   This loses the possibility of reifying individual players when
   there are more that have the same role, unless reifying the
   <topicRef> element could be said to have effect of reifying the
   topic's involvement in the association. My view is that that would
   work.  

Provided that I am right about the semantics of reifying <topicRef>
elements I would prefer the last alternative here.

--Lars M.



To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com

------------------------ Yahoo! Groups Sponsor ---------------------~-~>
eGroups is now Yahoo! Groups
Click here for more details
http://click.egroups.com/1/11231/0/_/337252/_/981719945/
---------------------------------------------------------------------_->

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com