Subject: [siprec] Schema errors relating to extensiondata

From: "Elwell, John" <[email-masked]>
Date: Fri, 9 Sep 2011 15:07:23 +0200

There are further schema errors relating to extension data.

First, there is no definition of type extensiondata. It seems an element of name extensiondata occurs in several parent elements. In the <recording/> element it is states:
     <xs:element name='extensiondata'>
        <xs:complexType>
            <xs:any     namespace='##other'
                        minOccurs='0'
                        maxOccurs='unbounded'
                        processContents='lax'/>
        </xs:complexType>

And in other places it states:
          <xs:element name="extensiondata" type="extensiondata"
               minOccurs="0"/>

This does not validate, because there is no definition of type extensiondata.

Second, type xs:any can only occur in certain places (e.g., in a sequence), and not at the top level of a complexType.

As a solution, I propose that in each of the 5 sequences in which we require extension data we simply include the following:
            <xs:any   namespace='##other'
                      minOccurs='0'
                      maxOccurs='unbounded'
                      processContents='lax'/>
This is in line with what is done elsewhere, e.g., RFC 6120 (XMPP).

Note that we COULD define a complexType extensiondata as a sequence, and within the <sequence/> element include xs:any. But this would increase what we get on the wire, i.e., we would get a sequence within a sequence, which is unnecessary.

Note also that with this proposed change we lose the identifier associated with the extensiondata element. I don't believe that is needed. If we had identical extensiondata associated with a number of different elements, there might be benefit in including it as an element only once and referencing it from other elements where it is identical. The benefit for trivial amounts of extension data would be minimal, or even negative because of the sequence within a sequence construct that you would end up with. For large amounts of identical extension data it might make the document shorter, but with the overhead of considerable complexity in needing always to ensure that all instances really are identical, and if one changes they all change. I think we may have discussed this in the past, and I don't recall the conclusion, but I really don't think the extra complexity of being able to reference an extensiondata element is worthwhile.

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: "Ravindran Parthasarathi" <[email-masked]>
Date: Wed, 14 Sep 2011 06:23:03 +0530

Hi John,

Thanks for the comments. Intention of extensiondata is to use in each
SIPREC metadata separately. Please let me know the following definition
works for you:

Extensiondata datatype definition:

         <xs:sequence>
                       maxOccurs='1'
                       processContents='lax'/>
         </xs:sequence>
       </xs:complexType>
     </xs:element>

Extensiondata datatype usage in each SIPREC metadata element:
<xs:element ref='extensiondata' minOccurs='0' maxOccurs='1'/>

Thanks
Partha

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf
>Of Elwell, John
>Sent: Friday, September 09, 2011 6:37 PM
>To: [email-masked]
>Subject: [siprec] Schema errors relating to extensiondata
>
>First, there is no definition of type extensiondata. It seems an
element
>of name extensiondata occurs in several parent elements. In the
><recording/> element it is states:
<partha> Here, extensiondata datatype is used to create an element
namely extensiondata </partha>

>Second, type xs:any can only occur in certain places (e.g., in a
>sequence), and not at the top level of a complexType.
>
>As a solution, I propose that in each of the 5 sequences in which we
>require extension data we simply include the following:
>Note that we COULD define a complexType extensiondata as a sequence,
and
>within the <sequence/> element include xs:any. But this would increase
>what we get on the wire, i.e., we would get a sequence within a
>sequence, which is unnecessary.

<partha> In fact, I copied the xs:any attributes from RFC 6120 as per
Peter advise and the intention of extensiondata is to introduce new
complextype in XML. </partha>
 
>
>Note also that with this proposed change we lose the identifier
>associated with the extensiondata element. I don't believe that is
>needed. If we had identical extensiondata associated with a number of
>different elements, there might be benefit in including it as an
element
>only once and referencing it from other elements where it is identical.
>The benefit for trivial amounts of extension data would be minimal, or
>even negative because of the sequence within a sequence construct that
>you would end up with. For large amounts of identical extension data it
>might make the document shorter, but with the overhead of considerable
>complexity in needing always to ensure that all instances really are
>identical, and if one changes they all change. I think we may have
>discussed this in the past, and I don't recall the conclusion, but I
>really don't think the extra complexity of being able to reference an
>extensiondata element is worthwhile.
>
>John (as individual)
>
>
>John Elwell
>_______________________________________________
>siprec mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/siprec

---

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

Partha,

In my opinion this introduces an unnecessary nesting of sequence elements. It is not in line with the technique used in RFC 6120, for example.

John (as individual) 

> From: Ravindran Parthasarathi [mailto:[email-masked]] 
> Sent: 14 September 2011 01:53
> To: Elwell, John; [email-masked]
> Cc: Peter Saint-Andre
> Subject: RE: [siprec] Schema errors relating to extensiondata
> 
> Hi John,
>

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Fri, 16 Sep 2011 04:56:32 +0530

Hi John,

In fact, I have updated xs:any schema attribute based on RFC 6120 as per
Peter suggestion. The example schema in Appendix A of RFC 6120 is as
follows:

<xs:element name='features'>
       <xs:complexType>
         <xs:sequence>
           <xs:any namespace='##other'
                   minOccurs='0'
                   maxOccurs='unbounded'
                   processContents='lax'/>
         </xs:sequence>
       </xs:complexType>
     </xs:element>

Please let me know whether you propose to any other mechanism like all,
groups or choice.

Thanks
Partha 

>From: Elwell, John [mailto:[email-masked]]
>Sent: Thursday, September 15, 2011 8:51 PM
>To: Ravindran Parthasarathi; [email-masked]
>Cc: Peter Saint-Andre
>In my opinion this introduces an unnecessary nesting of sequence
>elements. It is not in line with the technique used in RFC 6120, for
>example.
>
>John (as individual)
>
>> >Registered office: Brickhill Street, Willen Lake, Milton Keynes,
MK15
>> >0DJ.

---

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

Partha,

The schema for <session/>, for example, I think should be:

      <xs:complexType name="session">
          <xs:sequence>
            <xs:element name="associate-time" type="dateTime"
                   minOccurs="0"/>
            <xs:element name="disassociate-time" type="dateTime"
                   minOccurs="0"/>
            <xs:element name="reason" type="xs:string"
                   minOccurs="0"/>
            <xs:element name="group-ref" type="urnuuid"
                   minOccurs="0" maxOccurs="1"/>
            <xs:any namespace='##other'
                   minOccurs='0'
                   maxOccurs='unbounded'
                   processContents='lax'/>
          </xs:sequence>
          <xs:attribute name="id" type="urnuuid"
               use="required"/>
      </xs:complexType> 

Note that <session/> already comprises a sequence, so we don't need a nested sequence.

John (as individual)

> Sent: 16 September 2011 00:27
> >> >Siemens Enterprise Communications Limited is a Trademark 
> Licensee of
> >> >Siemens AG.

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Thu, 22 Sep 2011 23:17:05 +0530

Hi John,

I'm fine with your proposal as per our last meeting conclusion. 

We will update in the next revision in case nobody has objection to this
proposal.

Thanks
Partha

>Sent: Friday, September 16, 2011 8:29 PM
>> >> >needed. If we had identical extensiondata associated with a
number
>> of
>> >> >really don't think the extra complexity of being able to
reference
>> an

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 23 Sep 2011 08:29:51 +0200

Partha,

I don't think we agreed anything on XML representation of extension data at the last meeting, so I think we should discuss on today's call. Perhaps Ram can include this on one of his slides.

John

> Sent: 22 September 2011 18:47

---

From: "Ravindran Parthasarathi" <[email-masked]>
Date: Fri, 23 Sep 2011 12:10:27 +0530

John,

I was attempted to mention about the conclusion of extensiondata removal
from the metadata model. AFAIK, In case there is no separate metadata
block, there is no need of extra sequence in XML. 

I agree with you for the discussion on today meeting if required.

Thanks
Partha

>Sent: Friday, September 23, 2011 12:00 PM
>To: Ravindran Parthasarathi; [email-masked]; Ram Mohan R (rmohanr)
>Cc: Peter Saint-Andre
>I don't think we agreed anything on XML representation of extension
data
>at the last meeting, so I think we should discuss on today's call.
>Perhaps Ram can include this on one of his slides.
>
>John
>
>> >Note that <session/> already comprises a sequence, so we don't need
a
>> >nested sequence.
>> >> >> >associated with the extensiondata element. I don't believe
that
>> is