Subject: [siprec] XML elements and their relationship to objects

From: "Elwell, John" <[email-masked]>
Date: Wed, 7 Sep 2011 11:06:19 +0200

I have just realised something that I had not consciously realised before, but I would like to talk it through to ensure my understanding is correct and we are all on the same wavelength.

It seems to me that certain XML elements do not have a 1:1 relationship with an object in the model. There can be several instances of certain elements, all with the same unique ID (and therefore corresponding to the same object).

As an example, consider a <participant/> element. If a participant occurs in several sessions, there will be several <participant/> elements all with the same unique ID but referencing different <session/> elements. I reach this conclusion on the basis that a <participant/> element can only reference a single <session/> element.

A consequence of this is that when I "delete" a <participant/> element (by adding a dissociate time), I am not necessarily representing deletion of the object from the model, because other <participant/> elements representing the same object (same unique ID) might remain for other sessions.

So a <participant/> element represents the association of a participant object with a session, rather than representing a participant object. This ties in with our change to using associate-time and dissociate-time. Correct so far?

Secondly, a <stream> element can only refer to a single <session/> element. So if a stream occurs in several sessions, there will be several <stream/> elements all with the same unique ID but referencing different <session/> elements. So if I delete a <stream/> element, it does not necessarily mean deletion of a media stream object.

A further consequence is as follows. A <send/> or <receive/> element (child element of <participant/>) refers to a stream by its unique ID. But there could be several <stream/> elements, all with the same unique ID (but referencing different <session/> elements. Implicitly the reference should be to that particular <stream/> element that has the given unique ID AND refers to the same session ID that the <participant/> element refers to.

This seems to get very messy trying to validate an XML document. For example, what if I receive a <participant/> element with a <send/> or <receive/> child element that refers to a stream, but the only <stream/> element with that unique ID references a DIFFERENT <session/> element? Clearly there is something wrong with this, but is the SRS expected to do all this checking? It certainly seems over complex.

Also, can two <stream/> elements with the same unique ID (representing the same media stream object) reference different SDP labels? I guess they could, but then the only benefit of them having the same unique ID would be that it would give the SRS a clue that it can discard one of the RTP streams, since it will contain the same as the other. It would make more sense just to send one RTP stream, both <stream/> elements having the same label.

So although a stream object can have a lifetime outside a single session, this does not mean that we can reduce the XML by having only a single <stream/> element - it just means we can use the same unique ID (and most likely the same label).

Are all these assumptions correct? If so, we really need to get this understanding across to the reader a lot better. For example, in 6.4.3 "A participant element represents a Participant object" and in 6.5.3: "stream element represents a Media Stream object" - this is clearly not the whole story. But in addition, the difficulty I referred to above concerning validating a received XML document perhaps needs some consideration.

John (as individual)

John Elwell
Tel: +44 1908 817801 (office and mobile)
Email: [email-masked]
http://www.siemens-enterprise.com/uk/

Siemens Enterprise Communications Limited.
Registered office: Brickhill Street, Willen Lake, Milton Keynes, MK15 0DJ.
Registered No: 5903714, England.

Siemens Enterprise Communications Limited is a Trademark Licensee of Siemens AG.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 Sep 2011 10:56:55 -0400

John,

Before delving into specific details, I think there is a fundamental 
point here that may explain what you are concerned about:

The XML does not directly represent the model described in the UML. 
Rather, the UML represents the complete model stored at the SRS while 
the XML represents *changes* to that model.

And now that I say that, it is a reason that we need to retain the UML.

Alternatively, I suppose we could provide an XML representation of the 
complete model as it would exist at the SRS. I'm not sure I want to do 
that, since I don't expect that implementations will create a complete 
XML representation.

	Thanks,
	Paul

On 9/7/11 5:06 AM, Elwell, John wrote:
> As an example, consider a<participant/>  element. If a participant occurs in several sessions, there will be several<participant/>  elements all with the same unique ID but referencing different<session/>  elements. I reach this conclusion on the basis that a<participant/>  element can only reference a single<session/>  element.
>
> A consequence of this is that when I "delete" a<participant/>  element (by adding a dissociate time), I am not necessarily representing deletion of the object from the model, because other<participant/>  elements representing the same object (same unique ID) might remain for other sessions.
>
> So a<participant/>  element represents the association of a participant object with a session, rather than representing a participant object. This ties in with our change to using associate-time and dissociate-time. Correct so far?
>
> Secondly, a<stream>  element can only refer to a single<session/>  element. So if a stream occurs in several sessions, there will be several<stream/>  elements all with the same unique ID but referencing different<session/>  elements. So if I delete a<stream/>  element, it does not necessarily mean deletion of a media stream object.
>
> A further consequence is as follows. A<send/>  or<receive/>  element (child element of<participant/>) refers to a stream by its unique ID. But there could be several<stream/>  elements, all with the same unique ID (but referencing different<session/>  elements. Implicitly the reference should be to that particular<stream/>  element that has the given unique ID AND refers to the same session ID that the<participant/>  element refers to.
>
> This seems to get very messy trying to validate an XML document. For example, what if I receive a<participant/>  element with a<send/>  or<receive/>  child element that refers to a stream, but the only<stream/>  element with that unique ID references a DIFFERENT<session/>  element? Clearly there is something wrong with this, but is the SRS expected to do all this checking? It certainly seems over complex.
>
> Also, can two<stream/>  elements with the same unique ID (representing the same media stream object) reference different SDP labels? I guess they could, but then the only benefit of them having the same unique ID would be that it would give the SRS a clue that it can discard one of the RTP streams, since it will contain the same as the other. It would make more sense just to send one RTP stream, both<stream/>  elements having the same label.
>
> So although a stream object can have a lifetime outside a single session, this does not mean that we can reduce the XML by having only a single<stream/>  element - it just means we can use the same unique ID (and most likely the same label).
>
> _______________________________________________
> siprec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/siprec
>

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Thu, 8 Sep 2011 00:32:45 +0530

John,

I agree with Paul. Just adding more comments for clarification. 

UML to XML mapping for metadata is as follows:

1) UML objects (session, group) are mapped as XML element
2) Object's unique id attribute is mapped as XML attribute
3) Object's hierarchical association (session to stream, session to
participant) are represented as XML attribute (parent id). - Reason for
this approach is to make the partial update
4) Object's other associations (like participant to stream) are
represented as XML element.
5) Composition object (extensiondata) is mapped to XML element

Let us discuss about XML validation once some common understanding in
this high level approach.

Thanks
Partha

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf
>Of Paul Kyzivat
>Sent: Wednesday, September 07, 2011 8:27 PM
>To: [email-masked]
>Subject: Re: [siprec] XML elements and their relationship to objects
>
>John,
>
>> I have just realised something that I had not consciously realised
>before, but I would like to talk it through to ensure my understanding
>is correct and we are all on the same wavelength.
>>
>> It seems to me that certain XML elements do not have a 1:1
>relationship with an object in the model. There can be several
instances
>of certain elements, all with the same unique ID (and therefore
>corresponding to the same object).
>>
>> As an example, consider a<participant/>  element. If a participant
>occurs in several sessions, there will be several<participant/>
>elements all with the same unique ID but referencing
different<session/>
>elements. I reach this conclusion on the basis that a<participant/>
>element can only reference a single<session/>  element.
>>
>> A consequence of this is that when I "delete" a<participant/>
element
>(by adding a dissociate time), I am not necessarily representing
>deletion of the object from the model, because other<participant/>
>elements representing the same object (same unique ID) might remain for
>other sessions.
>>
>> So a<participant/>  element represents the association of a
>participant object with a session, rather than representing a
>participant object. This ties in with our change to using
associate-time
>and dissociate-time. Correct so far?
>>
>> Secondly, a<stream>  element can only refer to a single<session/>
>element. So if a stream occurs in several sessions, there will be
>several<stream/>  elements all with the same unique ID but referencing
>different<session/>  elements. So if I delete a<stream/>  element, it
>does not necessarily mean deletion of a media stream object.
>>
>> A further consequence is as follows. A<send/>  or<receive/>  element
>(child element of<participant/>) refers to a stream by its unique ID.
>But there could be several<stream/>  elements, all with the same unique
>ID (but referencing different<session/>  elements. Implicitly the
>reference should be to that particular<stream/>  element that has the
>given unique ID AND refers to the same session ID that
the<participant/>
>element refers to.
>>
>> This seems to get very messy trying to validate an XML document. For
>example, what if I receive a<participant/>  element with a<send/>
>or<receive/>  child element that refers to a stream, but the
>only<stream/>  element with that unique ID references a
>DIFFERENT<session/>  element? Clearly there is something wrong with
>this, but is the SRS expected to do all this checking? It certainly
>seems over complex.
>>
>> Also, can two<stream/>  elements with the same unique ID
(representing
>the same media stream object) reference different SDP labels? I guess
>they could, but then the only benefit of them having the same unique ID
>would be that it would give the SRS a clue that it can discard one of
>the RTP streams, since it will contain the same as the other. It would
>make more sense just to send one RTP stream, both<stream/>  elements
>having the same label.
>>
>> So although a stream object can have a lifetime outside a single
>session, this does not mean that we can reduce the XML by having only a
>single<stream/>  element - it just means we can use the same unique ID
>(and most likely the same label).
>>
>> Are all these assumptions correct? If so, we really need to get this
>understanding across to the reader a lot better. For example, in 6.4.3
>"A participant element represents a Participant object" and in 6.5.3:
>"stream element represents a Media Stream object" - this is clearly not
>the whole story. But in addition, the difficulty I referred to above
>concerning validating a received XML document perhaps needs some
>consideration.
>>
>> John (as individual)
>>
>>
>> John Elwell

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 9 Sep 2011 16:47:17 +0200

Paul,

Let me try to understand this better. Partial metadata updates have their own considerations, but let us consider only full metadata XML documents.

A full metadata XML document is a snapshot of the metadata at a given instant in time, and basically it lacks:
- Any elements representing objects that have been terminated (except for those just terminated and therefore included together with a dissociate time).
- Any past values of parameters of objects, those past values having been replaced by more up-to-date values.

An example of the first is a session that has completed and has no <session/> element in the XML document.

An example of the second is a <name/> element that has been added to a <participant/> element during a CS when the information became known. Another example is a <send/> element that is removed from a <participant/> element when that participant mutes the stream concerned.

I think what you are saying is that the SRS will keep all this historic information somehow, and the UML models what the SRS keeps. So the SRS will keep all terminated session, group, participant and stream objects, but they would be marked as terminated. I am not so sure about the second category. Would it really keep the fact that a name is absent for part of the recording but becomes known later, or would it just record the name against that participant for that participant's entire participation in the session?

The example of the <send/> element is a bit harder for me to comprehend, and that is partly because we haven't yet got associate and dissociate times for <send/> (and <recv/>) elements. Presumably the SRS would need to keep records of all instances of starting to send, stopping sending (and likewise starting to receive, stopping receiving). I don't see how the UML models that.

So I am not yet convinced that your assertion is correct. I can't really find anything in section 4 that makes it clear that the UML model reflects the stored data at the SRS, and not a snapshot conveyed in a complete metadata XML document. In fact the following text from section 4 is particularly confusing:
"The model allows the capture of a snapshot of a recording's Metadata
   at a given instant in time."
This certainly fails to suggest this significant difference between UML model and snapshot that you assert.

Anyway, if your assertion is correct, and if the WG is happy with that, I believe we would need new text to explain the difference between the UML model and a complete XML document.

John (as individual)

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: 07 September 2011 15:57
> To: [email-masked]
> > I have just realised something that I had not consciously 
> realised before, but I would like to talk it through to 
> ensure my understanding is correct and we are all on the same 
> wavelength.
> >
> relationship with an object in the model. There can be 
> several instances of certain elements, all with the same 
> unique ID (and therefore corresponding to the same object).
> >
> > As an example, consider a<participant/>  element. If a 
> participant occurs in several sessions, there will be 
> several<participant/>  elements all with the same unique ID 
> but referencing different<session/>  elements. I reach this 
> conclusion on the basis that a<participant/>  element can 
> only reference a single<session/>  element.
> >
> > A consequence of this is that when I "delete" 
> a<participant/>  element (by adding a dissociate time), I am 
> not necessarily representing deletion of the object from the 
> model, because other<participant/>  elements representing the 
> same object (same unique ID) might remain for other sessions.
> >
> associate-time and dissociate-time. Correct so far?
> >
> > Secondly, a<stream>  element can only refer to a 
> single<session/>  element. So if a stream occurs in several 
> sessions, there will be several<stream/>  elements all with 
> the same unique ID but referencing different<session/>  
> elements. So if I delete a<stream/>  element, it does not 
> necessarily mean deletion of a media stream object.
> >
> > A further consequence is as follows. A<send/>  or<receive/> 
>  element (child element of<participant/>) refers to a stream 
> by its unique ID. But there could be several<stream/>  
> elements, all with the same unique ID (but referencing 
> different<session/>  elements. Implicitly the reference 
> should be to that particular<stream/>  element that has the 
> the<participant/>  element refers to.
> >
> > This seems to get very messy trying to validate an XML 
> document. For example, what if I receive a<participant/>  
> element with a<send/>  or<receive/>  child element that 
> refers to a stream, but the only<stream/>  element with that 
> unique ID references a DIFFERENT<session/>  element? Clearly 
> there is something wrong with this, but is the SRS expected 
> to do all this checking? It certainly seems over complex.
> >
> (representing the same media stream object) reference 
> different SDP labels? I guess they could, but then the only 
> benefit of them having the same unique ID would be that it 
> would give the SRS a clue that it can discard one of the RTP 
> streams, since it will contain the same as the other. It 
> would make more sense just to send one RTP stream, 
> both<stream/>  elements having the same label.
> >
> > So although a stream object can have a lifetime outside a 
> single session, this does not mean that we can reduce the XML 
> by having only a single<stream/>  element - it just means we 
> can use the same unique ID (and most likely the same label).
> >
> > Are all these assumptions correct? If so, we really need to 
> get this understanding across to the reader a lot better. For 
> example, in 6.4.3 "A participant element represents a 
> Participant object" and in 6.5.3: "stream element represents 
> a Media Stream object" - this is clearly not the whole story. 
> But in addition, the difficulty I referred to above 
> concerning validating a received XML document perhaps needs 
> some consideration.
> >
> > John (as individual)
> >
> >
> > John Elwell

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 9 Sep 2011 16:58:25 +0200

> [mailto:[email-masked]] On Behalf Of Ravindran Parthasarathi
> Sent: 07 September 2011 20:03
> To: Paul Kyzivat; [email-masked]
[JRE] I possibly agree for <session/> and <group/> elements. But I disagree for <participant/> and <stream/> elements.
So consider a single participant that is participating in two sessions. The UML model would include a single participant object, correct? The XML would include TWO <participant/> elements, correct? Two are needed because a single <participant/> element cannot reference two <session/> elements.

So a <participant/> element does not have a 1:1 mapping to a participant object in the UML model. A <participant/> element seems to represent a participant participating in a given session. I am sure this is not obvious to a new reader.

> this high level approach.
[JRE] I think XML validation can be discussed now. My concerns with how XML relates to the model impact only to some extent what goes into the XML and therefore what appears on the wire. Modulo the extension data issue that I raised today, and the known issues with <send/> and <recv/> elements, I am reasonably comfortable with the XML.

John (as individual)

> document. For
> >> Registered office: Brickhill Street, Willen Lake, Milton 
> Keynes, MK15
> >0DJ.
> >> Siemens Enterprise Communications Limited is a Trademark 
> Licensee of
> >Siemens AG.
> >>
> >>
> >>
> >>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 09 Sep 2011 12:30:43 -0400

On 9/9/11 10:47 AM, Elwell, John wrote:
> An example of the first is a session that has completed and has no<session/>  element in the XML document.
>
> An example of the second is a<name/>  element that has been added to a<participant/>  element during a CS when the information became known. Another example is a<send/>  element that is removed from a<participant/>  element when that participant mutes the stream concerned.
>
> I think what you are saying is that the SRS will keep all this historic information somehow, and the UML models what the SRS keeps.

Yes.
Recordings are mostly about what happened in the past.
We "know" that an SRS will need to keep that historic information to 
make sense of the media recordings. But exactly how the SRS stores that 
data is out of scope for siprec.

The UML was a way to describe that, abstractly, without worrying about 
the details of how the SRS will store it, or even how much of it the SRS 
will store. It serves as a guide to help us figure out what needs to be 
transmitted from SRC to SRS.

> So the SRS will keep all terminated session, group, participant and stream objects, but they would be marked as terminated. I am not so sure about the second category. Would it really keep the fact that a name is absent for part of the recording but becomes known later, or would it just record the name against that participant for that participant's entire participation in the session?

IMO that is an implementation decision.

*If* we were to extend our scope to include querying the SRS for 
recordings, then we would have to be more specific about what the SRS 
retains. We aren't currently doing that. All we can do is provide the 
information and let the SRS keep what it wants, how it wants.

> The example of the<send/>  element is a bit harder for me to comprehend, and that is partly because we haven't yet got associate and dissociate times for<send/>  (and<recv/>) elements. Presumably the SRS would need to keep records of all instances of starting to send, stopping sending (and likewise starting to receive, stopping receiving). I don't see how the UML models that.

I think you are right, that this isn't currently expressed in the UML.
I guess over time we (including me) have lost sight of the need for that 
as we focused on the XML.

> So I am not yet convinced that your assertion is correct.

Well, that was at least my intent, from the beginning.
That it isn't clear to you is an indication that it hasn't been well 
documented.

> I can't really find anything in section 4 that makes it clear that the UML model reflects the stored data at the SRS, and not a snapshot conveyed in a complete metadata XML document. In fact the following text from section 4 is particularly confusing:

Yes, I agree.

	Thanks,
	Paul

>> Keynes, MK15 0DJ.
>> Licensee of Siemens AG.