Subject: [siprec] Deletion of nested XML elements

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

Further to my thoughts below, what if a session terminates? I can add a <dissociate-time/> child element to the <session/> element. If that session contains multiple participants (multiple <participant/> elements referring to this session) and/or multiple media streams (multiple <stream/> elements referring to this session, do I need to take action explicitly to show these as dissociated, or can it be implicit?

So can I send a complete metadata document showing <dissociate-time/> for the <session/> element and omitting all relevant <participant/> and <stream/> elements (their dissociate times being implicit)?

And can I send a partial metadata document showing <dissociate-time/> for the <session/> element and omitting all relevant <participant/> and <stream/> elements (again, their dissociate times being implicit)?

John

> -----Original Message-----
> From: Elwell, John 
> Sent: 07 September 2011 10:06
> To: [email-masked]
> Subject: XML elements and their relationship to objects
> 
> 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.
> 
> 
> 
> 
>