Subject: [siprec] #72: How to represent attributes of association in metadata Model and in XML ?

From: "siprec issue tracker" <[email-masked]>
Date: Fri, 02 Sep 2011 06:13:09 -0000

#72: How to represent attributes of association in metadata Model and  in XML ?

 How do we represent attributes of associations in the model ?

 During IETF 81 there was a consensus that certain attributes of some of
 the elements are actually attributes of association of that element to
 some other element. How do we represent such attributes in the UML model ?
 AFAIK Currently UML does not have a mechanism to represent attributes for
 the linkages. Should we just leave the model as it as and have the
 attributes listed inside the class boxes itself ?

 How do we represent attributes of association in XML ?
 we have certain attributes of participant (like capabilities), stream
 (like CSRC) which are attributes of association. There was some discussion
 on this here http://www.ietf.org/mail-
 archive/web/siprec/current/msg02475.html
 No conclusion is reached yet.

-- 
--------------------------------+-------------------------------------------
 Reporter:  rmohanr@…           |       Owner:  rmohanr@…        
     Type:  defect              |      Status:  new              
 Priority:  major               |   Milestone:                   
Component:  metadata            |     Version:                   
 Severity:  Active WG Document  |    Keywords:                   
--------------------------------+-------------------------------------------

Ticket URL: <http://wiki.tools.ietf.org/wg/siprec/trac/ticket/72>
siprec <http://tools.ietf.org/siprec/>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 2 Sep 2011 14:55:08 +0200

My guess is that in UML anything that requires attributes would be regarded as an object, not an association.

John 

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of siprec issue tracker
> Sent: 02 September 2011 07:13
> To: [email-masked]
> Cc: [email-masked]
> Subject: [siprec] #72: How to represent attributes of 
> association in metadata Model and in XML ?
> 
>  Reporter:  rmohanr@...           |       Owner:  rmohanr@...        
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Sep 2011 10:59:32 -0400

> My guess is that in UML anything that requires attributes would be regarded as an object, not an association.

I've been trying to avoid the more advanced features of UML, since its 
unfamiliar to many. But UML does have something called an Association 
Class, which can be used to specify properties of an association.

Taking slight liberty with the notation to make it work with text art, 
you show this as:

   +---------+                   +---------+
   |   Foo   |-------------------|   Bar   |
   +---------+         .         +---------+
                       .
                       .
                       .
               +---------------+
               |  FooBarAssoc  |
               |---------------|
               | Attr1         |
               | Attr2         |
               | ...           |
               | AttrN         |
               +---------------+

	Thanks,
	Paul

>> Ticket URL:<http://wiki.tools.ietf.org/wg/siprec/trac/ticket/72>
>> siprec<http://tools.ietf.org/siprec/>
>>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Sat, 3 Sep 2011 14:29:17 +0530

Hi Paul,

Please see inline

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Kyzivat
> Sent: Friday, September 02, 2011 8:30 PM
> To: [email-masked]
> Subject: Re: [siprec] #72: How to represent attributes of association
> in metadata Model and in XML ?
> 
> > My guess is that in UML anything that requires attributes would be
> regarded as an object, not an association.
> 

Thanks for sharing your knowledge of UML here. I was not aware that UML
has association classes too. I also see from UML tutorial online that
there is association attributes also.
In IETF 81 we agreed that several attributes are actually attributes of
association between classes. 
Should we define association class for each of those associations and
list all those attributes ?

e.g.
I think there was a consensus that capabilities of a participant is a
attribute of association of participant to session since a participant
in different sessions can have different capabilities
Also times (association/disassociation ) are a property of association.

So If I go by the above example, is the below representation right to
show Participant to CS linkage ? 
               +-------------------------------+               
               |   Communication Session (CS)  |       
               |                               |
               +-------------------------------+
               |                               |
               |   CS Identifier               |
               |   Termination Reason          |
               |   Start Time                  |
               |   End Time                    |
               +-------------------------------+
                              |1..* 
                              |
     +------------------+     |
     |ParticipantCSAssoc|     |
     +------------------+     |
     |capabilities      |     |
     |AssociationTime   |.....|
     |DisassociationTime|     |
     |                  |     |
     +------------------+     | 
                              |
                              |
                              |
                              |
                              | 2..*
                    +------------------+
                    | Participant      |
                    +------------------+
                    |  AoR list        |
                    |  Name            |
                    +------------------+
For the sake of simplicity I did not show the other classes here.

Regards,
Ram

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 5 Sep 2011 11:29:21 +0200

This might be a promising approach. My concern is that we might be demanding too much of the reader by requiring an understanding of additional UML constructs in order to understand the document.

John (as individual) 

> [mailto:[email-masked]] On Behalf Of Ram Mohan R (rmohanr)
> Sent: 03 September 2011 09:59
> To: Paul Kyzivat; [email-masked]
> Subject: Re: [siprec] #72: How to represent attributes of

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Mon, 5 Sep 2011 20:00:25 +0530

John,

I agree that the reader of the document need to have a understanding of
UML to interpret the class diagram.
we can add some more text in the next version to explain the diagram if
the existing text is not sufficient.

If you have any other simpler mechanism to represent the association
classes, I am open to discuss on the same.

Regards,
Ram

> From: Elwell, John [mailto:[email-masked]]
> Sent: Monday, September 05, 2011 2:59 PM
> To: Ram Mohan R (rmohanr); Paul Kyzivat; [email-masked]
> Subject: RE: [siprec] #72: How to represent attributes of association
> inmetadata Model and in XML ?
> 
> This might be a promising approach. My concern is that we might be
> demanding too much of the reader by requiring an understanding of
> additional UML constructs in order to understand the document.
> 
> John (as individual)
> 
> > > >>   the linkages. Should we just leave the model as it as and
have
> > the
> > > >>   we have certain attributes of participant (like
capabilities),
> > > stream
> > > >> Ticket
URL:<http://wiki.tools.ietf.org/wg/siprec/trac/ticket/72>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Sep 2011 14:32:27 -0400

> This might be a promising approach. My concern is that we might be demanding too much of the reader by requiring an understanding of additional UML constructs in order to understand the document.

That is why I avoided it to date.
But it seems the corresponding semantics are needed.
There is an alternative that avoids using the association class - 
instead, represent the association as a regular class. There are 
technical arguments for why not to do this, but in simple cases it can 
generally be used.

Just use:

     +---------+                   +---------+
     |   Foo   |----+         +----|   Bar   |
     +---------+    |         |    +---------+
                    |         |
                    |         |
                    |         |
                 +---------------+
                 |  FooBarAssoc  |
                 |---------------|
                 | Attr1         |
                 | Attr2         |
                 | ...           |
                 | AttrN         |
                 +---------------+

But it will take some additional words to make clear what is going on. 
And it gets cumbersome if you use it a lot.

I can live with either approach.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 Sep 2011 14:38:16 -0400

> This might be a promising approach. My concern is that we might be demanding too much of the reader by requiring an understanding of additional UML constructs in order to understand the document.

One more thing:

The UML notation is not all that difficult to learn.
Its well worth taking the time to develop at least a reading knowledge 
of it, even if you don't get comfortable enough to write it easily.

It shares those characteristics with XML. I'm not an expert in XML, but 
I can read most XML schemas I come across.

IMO the advantage of UML is that it is very concise - you can express a 
*lot* in one or two diagrams. So it provides a way to have a high level 
discussion without getting embroiled in implementation details.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 6 Sep 2011 21:28:13 +0200

Paul,

Yes, the second approach you show was the alternative I had in mind, i.e., just introduce another class.

This discussion, together with some concerns I have on how the model is described in the draft, got me wondering about use of UML in the final deliverable. I will start a new thread.

John

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 06 September 2011 19:32
> To: Elwell, John
> Cc: Ram Mohan R (rmohanr); [email-masked]
> > This might be a promising approach. My concern is that we 
> might be demanding too much of the reader by requiring an 
> understanding of additional UML constructs in order to 
> understand the document.
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 6 Sep 2011 21:30:21 +0200

> Sent: 06 September 2011 19:38
> To: Elwell, John
[JRE] Yes, it is great for having that high level discussion - I am just not sure it is the best tool for documenting the results - see the other thread I just started.

John

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 22 Sep 2011 15:41:25 +0530

I have not seen any inputs on this so far. In the last discussion we had on Monday we discussed to ways to represent attributes of association. Can folks look at these and provide inputs and also other ways to represent attributes of association ?

Use-case:
---------
A participant who is simultaneously in multiple sessions having different capabilities(this attribute is an attribute of association).

Approach 1:
-----------
Session 1 having participant 1:
        <participant
           id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"
           session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"> 
                 <aor>sip:[email-masked]</aor>
                 <associate-time>2010-12-16T23:41:07Z</associate-time>
                 <capabilities> TBD</capabilties>
         </participant>
Session 2 having the same participant 1:

        <participant
            id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"
            session="urn:uuid:cd27cfa1-2bdd-4830-a653-70374d10f103">
                 <aor>sip:[email-masked]</aor>
                 <associate-time>2010-12-16T23:41:07Z</associate-time>
                 <capabilities> TBD</capabilties>
         </participant>

Here the session ID is different and it's the same participant ID across both sessions.

In this approach all the association attributes are encoded within the <participant> element as the participant already has session ID of the session to which it is associated.

Pros: This is simple as we are just adding capabilities to the existing participant element and hence it does not require any additional ID.

Note there was some discussions on this earlier at- http://www.ietf.org/mail-archive/web/siprec/current/msg02464.html

Approach 2:
----------

Have a separate XML element that represents an instance of the association class between participant and session

<participantSessionAssoc participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3”  session="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425">
                <associate-time>2010-12-16T23:41:07Z</associate-time>
                 <capabilities> TBD</capabilties>
       </participantSessionAssoc>

Pros: if the participant has same capabilities across sessions we can avoid encoding it twice as it kept outside participant  element.
Cons: Need to see if this will end up in having another ID which may not be desirable as we already have several Ids.

Please suggest other approaches folks have in mind to encode Association class.

Regards,
Ram

> From: siprec issue tracker [mailto:[email-masked]]
> Sent: Friday, September 02, 2011 11:43 AM
> To: Ram Mohan R (rmohanr)
> Cc: [email-masked]
> Subject: [siprec] #72: How to represent attributes of association in
> metadata Model and in XML ?
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 22 Sep 2011 17:17:04 +0200

> Sent: 22 September 2011 11:11
> To: siprec issue tracker
> Cc: [email-masked]
> I have not seen any inputs on this so far. In the last 
> discussion we had on Monday we discussed to ways to represent 
> attributes of association. Can folks look at these and 
> provide inputs and also other ways to represent attributes of 
> association ?
> 
> Use-case:
> ---------
> A participant who is simultaneously in multiple sessions 
> having different capabilities(this attribute is an attribute 
> of association).
> 
> Approach 1:
> -----------
> In this approach all the association attributes are encoded 
> within the <participant> element as the participant already 
> has session ID of the session to which it is associated.
> 
> Pros: This is simple as we are just adding capabilities to 
> the existing participant element and hence it does not 
> require any additional ID.
[JRE] If I understand the proposal correctly there is a possible problem. The example shows two <participant/> elements with the same unique ID. If the SRC sends a partial update that contains a <participant/> element, the SRS can't use its unique ID alone to identify the particular element that has changed. The SRS has to use the combination of the element's unique ID and the referenced session unique ID. I am not sure this is a problem, but it is certainly a change from what we have discussed in the past, and it means rules for matching become more complex. To some extent it defeats the purpose of having a unique ID for a participant.

Let's try another case. The SRC sends a partial update with a <participant/> element whose referenced session is different from that of any existing <participant/> element with that same unique ID. Does this mean the SRS has to add a new <participant/> element to its model? Again this seems to be contrary to my earlier understanding that you only add something if you receive something with a new unique ID.

I believe up till now a complete XML document would never have two elements with the same unique ID. This principle (if that was people's understanding) now seems to be destroyed.

Basically the combination of <participant/> unique ID and <session/> unique ID becomes the unique ID for the association - not necessarily wrong, but I do wonder whether having a unique ID for a participant element is rather pointless when it alone is not usable as unique identification for an element.

John (as individual)

> 
> Note there was some discussions on this earlier at- 
> http://www.ietf.org/mail-archive/web/siprec/current/msg02464.html
> 
> Approach 2:
> ----------
> 
> Have a separate XML element that represents an instance of 
> the association class between participant and session
> 
> <participantSessionAssoc 
> participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3"  
> Pros: if the participant has same capabilities across 
> sessions we can avoid encoding it twice as it kept outside 
> participant  element.
> Cons: Need to see if this will end up in having another ID 
> which may not be desirable as we already have several Ids.
> 
> > #72: How to represent attributes of association in metadata 
> Model and
> > in XML ?
> > 
> >  During IETF 81 there was a consensus that certain 
> attributes of some
> > of
> >  AFAIK Currently UML does not have a mechanism to represent 
> attributes
> > for
> capabilities), stream
> --------------------------------+-----------------------------
> ---------
> > -----
> --------------------------------+-----------------------------
> ---------
> > -----
> >

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Thu, 22 Sep 2011 22:27:00 +0530

Hi John,

Please see inline.

> Sent: Thursday, September 22, 2011 8:47 PM
> To: Ram Mohan R (rmohanr); siprec issue tracker
> Cc: [email-masked]
> [JRE] If I understand the proposal correctly there is a possible
> problem. The example shows two <participant/> elements with the same
> unique ID. If the SRC sends a partial update that contains a
> <participant/> element, the SRS can't use its unique ID alone to
> identify the particular element that has changed. The SRS has to use
> the combination of the element's unique ID and the referenced session
> unique ID. I am not sure this is a problem, but it is certainly a
> change from what we have discussed in the past, and it means rules for
> matching become more complex. To some extent it defeats the purpose of
> having a unique ID for a participant.

True. I agree with your point. The last time this proposal was made by
Partha, I remember there was a feedback on the similar lines. This issue
is going to be present for any attribute of participant not just
association attribute whenever a participant is simultaneously present
in multiple sessions.

As you mentioned below the combination of participant ID and session ID
(association) can serve as unique ID in cases where a participant is
simultaneously in multiple sessions.

Ram

> 
> Let's try another case. The SRC sends a partial update with a
> <participant/> element whose referenced session is different from that
> of any existing <participant/> element with that same unique ID. Does
> this mean the SRS has to add a new <participant/> element to its
model?
> Again this seems to be contrary to my earlier understanding that you
> only add something if you receive something with a new unique ID.
> 
> I believe up till now a complete XML document would never have two
> elements with the same unique ID. This principle (if that was people's
> understanding) now seems to be destroyed.
> 
> Basically the combination of <participant/> unique ID and <session/>
> unique ID becomes the unique ID for the association - not necessarily
> wrong, but I do wonder whether having a unique ID for a participant
> element is rather pointless when it alone is not usable as unique
> identification for an element.
> 
> John (as individual)
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 23 Sep 2011 09:31:28 +0200

Ram,

I don't like having to use the combination of participant unique ID and session unique ID for uniquely identifying a <participant/> element as proposed in approach 1, and therefore of the two approaches here I prefer approach 2.

Unfortunately approach 2 gets extremely verbose, particularly if we apply the same approach to associations between stream and participant. Consider a 20 party conference with 2 streams, audio and video (not an extreme example, but good enough to illustrate my point). Each participant is sending and receiving both streams. This means 80 associations between participant and stream. Each association element has its own unique ID, plus IDs referencing a <participant/> element and a <stream/> element. A total of 240 unique IDs on the wire just to represent these associations. Taking the example unique ID below with 45 characters, this is 10800 characters for the IDs alone. I am not sure whether this is a problem of not.

A couple of alternative approaches:

Approach 3: Define local IDs as aliases for globally unique IDs. This approach reduces the number of unique IDs on the wire per association from 3 to 1, replacing them with local IDs. Of course, the local IDs have to be defined. This might marginally penalize the VERY simple cases, but saves significantly for more complex situations.
e.g.:
<session
	id="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425"
	local="123">
...
</session>

<participant
	local="234">
...
</participant>

<participantSessionAssoc
	id="urn:uuid:acdf43ee-1441-478d-4eca-4d4f555a896d"
	participant="234"
	session="123">
...
</participantSessionAssoc

Approach 4: Encapsulate associations within one of the object elements concerned, e.g., encapsulate sequence of participants in the <session/> element. This approach reduces the number of unique IDs on the wire per association from 3 to 1.
e.g.:
<session
	id="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425">
....
  <sessionParticipant
	participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3">
    ....
  </sessionParticipant>  	  
</session>

<participant
	id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3">
...
</participant>

Or alternatively:
<session
	id="urn:uuid:855a5ded-8420-456d-a70f-6da1eeaeb425">
....
  <participants>
    <sessionParticipant
	  participant="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3">
      ....
    </sessionParticipant>
  </participants>
</session>

<participant
	id="urn:uuid:b2b7c112-5982-469d-9007-6ddbecca64d3">
...
</participant>

A further remark on approach 4. This means that you can't send a partial update conveying only an association - you have to send the whole element in which the association is embedded. So in the example above, if a participant drops out of a session you would have to send the whole <session/> element. So this might be a reason for embedding the associations in a <participant/> element instead, if we consider a given participant is unlikely to be in more than a handful of sessions.

John (as individual)

> From: Ram Mohan R (rmohanr) [mailto:[email-masked]] 
> Sent: 22 September 2011 17:57
> To: Elwell, John; siprec issue tracker
> Cc: [email-masked]
> Subject: RE: [siprec] #72: How to represent attributes of 
> association inmetadata Model and in XML ?
> 
> Hi John,
> 
> Please see inline.
>

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Fri, 23 Sep 2011 13:32:24 +0530

John,

Lets discuss these two approaches along with the other two in today's
meeting. I have added these to the slides.

Regards,
Ram

> Sent: Friday, September 23, 2011 1:01 PM
> I don't like having to use the combination of participant unique ID
and
> session unique ID for uniquely identifying a <participant/> element as
> proposed in approach 1, and therefore of the two approaches here I
> prefer approach 2.
> 
> Unfortunately approach 2 gets extremely verbose, particularly if we
> apply the same approach to associations between stream and
participant.
> Consider a 20 party conference with 2 streams, audio and video (not an
> extreme example, but good enough to illustrate my point). Each
> participant is sending and receiving both streams. This means 80
> associations between participant and stream. Each association element
> has its own unique ID, plus IDs referencing a <participant/> element
> and a <stream/> element. A total of 240 unique IDs on the wire just to
> represent these associations. Taking the example unique ID below with
> 45 characters, this is 10800 characters for the IDs alone. I am not
> sure whether this is a problem of not.
> 
> Approach 3: Define local IDs as aliases for globally unique IDs. This
> approach reduces the number of unique IDs on the wire per association
> from 3 to 1, replacing them with local IDs. Of course, the local IDs
> have to be defined. This might marginally penalize the VERY simple
> cases, but saves significantly for more complex situations.
> e.g.:
> <session
> Approach 4: Encapsulate associations within one of the object elements
> concerned, e.g., encapsulate sequence of participants in the
<session/>
> element. This approach reduces the number of unique IDs on the wire
per
> association from 3 to 1.
> A further remark on approach 4. This means that you can't send a
> partial update conveying only an association - you have to send the
> whole element in which the association is embedded. So in the example
> above, if a participant drops out of a session you would have to send
> the whole <session/> element. So this might be a reason for embedding
> the associations in a <participant/> element instead, if we consider a
> given participant is unlikely to be in more than a handful of
sessions.
> > > >                  <aor>sip:[email-masked]</aor>
<associate-time>2010-12-16T23:41:07Z</associate-
> > > time>
<associate-time>2010-12-16T23:41:07Z</associate-
> > > time>