Subject: [MMUSIC] Implementation specific comments on "draft-ietf-mmusic-sdpng-04"

From: Teodora Guenkova <[email-masked]>
Date: Wed, 22 May 2002 17:30:12 +0200

Dear MMUSIC Folks,

We have implemented at our university a parsing application for SDPng
and have countered some problems. The reason may be some misinterpreting
of draft-ietf-mmusic-sdpng-04.txt or some minor inconsistencies of the
draft itself.
Since we are interested in the further development of SDPng (also in
terms of QoS), we would like to raise a discussion on the discovered
problems, by delivering some comments coming from our experience with
the current version of SDPng (read below the line bordered text).
I hope these comments would help to improve SDPng and make it easily
understandable to the implementers.

Best regards,
 Teodora Guenkova-Luy
(Dept. Distributed Systems, University of Ulm,
Oberer Eselsberg, 89069 Ulm, Germany
Tel.: +49 (0731) 502-4148
FAX: +49 (0731) 502-4142
e-Mail: [email-masked])
______________________________________________________________

Comments on Session Description and Capability Negotiation
Internet-Draft
(draft-ietf-mmusic-sdpng-04.txt)

Document Structure:
1. Implementation Notes
2. Comments on the SDPng namespace definition
2.1 Proposed solution
2.2 Discussion
3. Comments on the SDPng Draft examples
3.1 Proposed solution
3.2 Discussion
4. Comments on <cfg> element compliance to the defined SDPng XML-schema
5. Comments on the usage of <rtp:udp> as a nested element
6. Comments on the RTP-Profile definition within the SDPng XML-Schema
6.1 Proposal
6.2 Possible solution
7. Comments on the usage of the <transport> element as attribute
8. Comments on the <use> and the <prop> elements
8.1 Discussion
8.2 Questions
8.3 General considerations on the XML inner-document referencing

1. Implementation Notes

These comments emerge from parsing-tests of an SDPng instance document
(defined for test purpose only), and deal with this
draft-ietf-mmusic-sdpng-04.txt from the XML side only. SDPng instance
document used in these tests has been based on examples given in
“Session Description and Capability Negotiation” Internet-Draft
(draft-ietf-mmusic-sdpng-04.txt).

SDPng document conformance to SDPng Base Definition has been tested,
with SDPng Base Definition, Audio Profile, and RTP Profile defined
identically to their definitions in "draft-ietf-mmusic-sdpng-04.txt".

Used Parsing Tools:
- Xerces-J 1.4.4 Java parser from Apache, used as SAX-parser to enable
generation of custom Java objects and object trees.
- XSV, an Open Source XML Schema Validator, from University of
Edinburgh/W3C (beta).

The indicated pages and paragraphs correspond the commented XML code of
draft-ietf-mmusic-sdpng-04.txt.
The draft-ietf-mmusic-sdpng-04.txt is also referenced in the following
comments as “Draft”.

2. Comments on the SDPng namespace definition

2.1 Proposed solution

Page 42, paragraph 1(XML) should read:

<?xml version="1.0" ?>
   <desc xmlns="http://www.iana.org/sdpng"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="http://www.iana.org/sdpng sdpng.xsd">

Page 44, Chapter 5.4, paragraph 3(XML) should read:

<desc xmlns="http://www.iana.org/sdpng"
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
            xsi:schemaLocation="http://www.iana.org/sdpng sdpng.xsd"
            xmlns:audio="http://www.iana.org/sdpng/audio"
            xmlns:rtp="http://www.iana.org/sdpng/rtp">

2.2 Discussion

In this way default namespace is declared for a SDPng instance document,
thus enabling each element to be implicitly qualified (without the
prefix). This change is necessary in case the intention is to use
qualified elements without prefix in a SDPng document (as it has been
done throughout the Draft).
SDPng instances based on <sdpng:desc> element as declared in the Draft
would not be Schema-compliant due to the following:
· all global elements must be qualified,
· in the example given in the Draft only <desc> element is qualified
(explicitly), since no default namespace is defined.

Please also note the case of character "i" in ".../XMLSchema-instance".

It should be considered that if a recommendation is to use <sdpng:desc>
element as declared in the Draft, all other elements from the "sdpng
namespace" need to be explicitly qualified in order to achieve
Schema-compliance. In other words, in an SDPng instance document,
instead of def, cfg, alt, etc., one needs to write sdpng:def, sdpng:cfg,
sdpng:alt, etc.

3. Comments on the SDPng Draft examples

3.1 Proposed solution

Page 11, paragraph 4(XML), should read:

   <cfg>
     <c name="interactive-audio" media="audio">
       <alt name="AVP-audio-0">
         <rtp:session format="rtp-avp-0">
          <rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
         </rtp:session>
       </alt>

       <alt name= AVP-audio-11">
         <rtp:session format="rtp-avp-11">
          <rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
         </rtp:session>
       </alt>
      </c>
   </cfg>

Page 12, paragraph 3(XML), should read:

<cfg>
     <c name="audio1" media="audio">
       <alt name="AVP-audio-0">
         <rtp:session>
          <rtp:pt pt="0">
           <audio:codec name="audio-basic" encoding="PCMU"
                        sampling="8000" channels="1"/>
          </rtp:pt>
          <rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
         </rtp:session>
       </alt>
      </c>
   </cfg>

Page 12, paragraph 5(XML), should read:

   <cfg>
     <c name="audio1" media="audio">
       <alt name="AVP-audio-0">
         <rtp:session format="rtp-avp-0">
          <rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801">
           <option name="ssm" sender="sender.example.com"/>
          </rtp:udp>
         </rtp:session>
       </alt>
      </c>
   </cfg>

Pages 18/19, paragraph 5(XML), should read:

  <cfg>
     <c name="interactive-audio" media="audio">
       <alt name="AVP-audio-0">
         <rtp:session format="rtp-avp-0">
          <rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
         </rtp:session>
       </alt>

       <alt name="AVP-audio-11">
          <rtp:udp addr="224.2.0.53" rtp-port="7800" rtcp-port="7801"/>
         </rtp:session>
       </alt>
      </c>
   </cfg>

Page 61, paragraph 4(XML), should read:

   <cfg>
     <c name="interactive-audio" media="audio">
       <alt name="AVP-audio-0">
         <rtp:session format="rtp-avp-0">
          <rtp:udp role="receive" endpoint="A" addr="192.168.1.1"
                rtp-port="7800"/>
         </rtp:session>
       </alt>
      </c>
   </cfg>

Page 63, paragraph 1(XML), should read:

   <cfg>
     <c name="interactive-audio" media="audio">
       <alt name="AVP-audio-0">
         <rtp:session format="rtp-avp-0">
          <rtp:udp role="receive" endpoint="A" addr="192.168.1.1"
                rtp-port="7800"/>
          <rtp:udp role="receive" endpoint="B" addr="192.168.1.2"
                rtp-port="9410"/>
         </rtp:session>
       </alt>
      </c>
   </cfg>

Page 64, paragraph 4(XML), should read:

   <cfg>
     <c name="interactive-audio" media="audio">
       <alt name="AVP-audio-0">
         <rtp:session format="rtp-avp-0" transport="A-rcv""/>
       </alt>
       <alt name="AVP-audio-18">
         <rtp:session format="rtp-avp-18" transport="A-rcv"/>
       </alt>
      </c>
   </cfg>

Page 66, paragraph 1(XML), should read:

   <cfg>
     <c name="interactive-audio" media="audio">
       <alt name="AVP-audio-0">
         <rtp:session format="rtp-avp-0" transport="A-rcv B-rcv"/>
       </alt>
      </c>
   </cfg>

3.2 Discussion

Element <sdpng:c> should be used instead of <component> (This is
according to the SDPng XML-schema definition), as it has already been
done in the rest of this document.

In addition, one could consider renaming <sdpng:c> element to
<sdpng:component> in the XML-schema. This consideration corresponds a
requirement from the XML 1.0 specification which states that  XML
documents should be human readable and reasonably clear. The proposed
change or any other more informative name would enhance readability of
an SDPng document.

The same remark about the name readability of the SDPng XML-components
should be also considered for the cases of the “Definition”,
“Constraint”, “SessionConfig" abstract type definitions and the
definitions, which should be used in parallel as constraints.

4. Comments on <cfg> element compliance to the defined SDPng XML-schema

Configuration sections (<cfg> elements) given on pages 11, 12, 18, 19,
61, and 63 of the Draft (all of which are listed in the comments on the
Draft examples) are not Schema-compliant due to the following:
- It should be noted that according to its definition in RTP Profile,
element <rtp:session> must contain at least one occurrence of  element
<rtp:transport>, and this condition is not met in given examples.
- Since <rtp:transport> is an element of abstract type Transport (please
see RTP Profile), it cannot be instantiated directly, but only in one of
its derived forms. According to W3C XML Schema specifications, one has
to regard such element as the head of a substitution group, and
therefore the element needs to be globally defined.
- SDPng Base Definition and accompanying profiles in their present form
do not allow <rtp:udp> element to be nested within <rtp:session> element
at all. One possible solution would be to declare <rtp:udp> element as
belonging to a substitution group headed by <rtp:transport>.

5. Comments on the usage of <rtp:udp> as a nested element

These comments also refer to RTP profile definition within the SDPng
XML-schema. Examples in the section 3.3 of the Draft (pages 20, 21, 22,
23, 24, 25, 26, and 27), as well as those in the section 6.2 (pages 64,
and 66) contain <rtp:udp> element within the Definitions section, i.e.
nested within <def> element. Argumentation similar to that presented in
the comment on the <cfg> element (see above)  holds again here. SDPng
Base Definition and accompanying profiles in their present form do not
allow <rtp:udp> element to be nested within <def> element.

6. Comments on the RTP-Profile definition within the SDPng XML-Schema

6.1 Proposal

This proposal is only one of a number of possible solutions which
necessarily introduce minor changes to RTP Profile, while maintaining
required XML-side functionality, reflected in examples throughout the
Draft. This proposal concerns the comments on the <cfg> and the
<rtp:udp> elements of this document.

- Define element <rtp:udp> in RTP Profile as follows:

<xsd:element name="udp" type="rtp:UDP"
substitutionGroup="rtp:transport"/>

- Define <rtp:transport> globally in RTP Profile:

<xsd:element name="transport" type="rtp:Transport"
substitutionGroup="sdpng:d"/>

These two changes would allow <rtp:udp> element to be nested within
<def> element in an instance SDPng document. (please refer to the
comment on the <cfg> element above).

Furthermore, allowing <rtp:udp> element to be referenced by
<rtp:session> element would enable <rtp:session> to contain <rtp:udp>
element.

6.2 Possible solution

Definition of complexType Session (RTP Profile) is as follows:

<xsd:complexType name="Session" mixed="false">
       <xsd:complexContent mixed="false">
         <xsd:extension base="sdpng:SessionConfig">
        <xsd:sequence>
         <xsd:element ref="rtp:udp" minOccurs="0"/>
        </xsd:sequence>
        <xsd:attribute name="format" type="xsd:string"/>
         </xsd:extension>
       </xsd:complexContent>
     </xsd:complexType>

7. Comments on the usage of the <transport> element as attribute

This comment is closely connected with the comments on the <cfg>,
<rtp:udp> and the RTP-Profile definition (see above). Namely, in
examples on pages 64, 66 of the SDPng Draft, element <rtp:session> has
been instantiated as follows:

<rtp:session format="rtp-avp-0" transport="A-rcv"/>

There is no "transport" attribute defined for element <rtp:session> in
SDPng Base Definition, thereof no such instantiation of element
<rtp:session> is possible.

If necessary, attribute <transport> can be additionally defined within
complexType Session, pointing to corresponding <rtp:udp> element in
Definitions section. Therefore, complexType Session can be rewritten to
include also this attribute:

     <xsd:complexType name="Session" mixed="false">
       <xsd:complexContent mixed="false">
         <xsd:extension base="sdpng:SessionConfig">
        <xsd:sequence>
         <xsd:element ref="rtp:udp" minOccurs="0"/>
        </xsd:sequence>
        <xsd:attribute name="format" type="xsd:string"/>
        <xsd:attribute name="transport" type="xsd:string"/>
         </xsd:extension>
       </xsd:complexContent>
     </xsd:complexType>

However, from an XML point of view, the same functionality has been
already achieved by means of <sdpng:use> element, thus almost
eliminating the need for "transport" attribute with the described
properties.

8. Comments on the <use> and the <prop> elements

8.1 Discussion

To summarize briefly, the <use> element proposed in section 3.3 of the
Draft allows flexible referencing of previously defined and named
entities. Additionally, using the <prop> element, these references can
be arbitrarily customized.

But there are some problems and issues with this approach.

a. Formal definition of the <use> and <prop> element

The formal definition of SDPng as given in section 5 of the Draft does
not provide a formal definition of the elements in question. Considering
the consequences of such a definition, it becomes clear that in order to
obtain valid documents under the employment of the <use> element, this
element has to be in the content model of (virtually) all elements.
So it would be possible to write valid documents that utilizes the <use>
element but it is easily imaginable that after the replacement algorithm
for the <use> element as described in the Draft and by  resolving all
references, the resulting expanded document is no longer valid under the
SDPng schema.
Since the use of the <use> element is not constrained at all – it may be
applied as a child under any other element and it may reference any
previously defined entity  (Note: references to prohibited entities are
thus also possible!!!).So the parser will happily parse such a document
and report it as valid. The resulting structure can be further applied
as input to the replacement algorithm, which is designed to resolve all
references, since  <use> elements may reference any previously defined
entity. As a result the replacement algorithm should be able to support
custom validation of the XML objects, since by applying the <use>
element any combination of sub-elements would be possible. This problem
is currently not considered in the Draft.

The <prop> element introduces similar problems.

b. Considering XML and Schema design goals

The XML 1.0 specification identifies ten design goals of XML. According
to this list, XML documents should be human readable and reasonably
clear, and as a consequence thereof, XML documents are self-describing
to a large extent. Considering this point  the <use> element does not
really meet this design goal, since its expressive power as long as it
has not been resolved is quite weak.

The XML Schema provides means for expressing very strong typing and
concise structure rules for XML documents. The <use> element is
inherently untyped and is allowed at almost any  point in the SDPng
document structure, which contradicts the wish for a formal definition
of SDPng.

c. Processing of documents

The replacement algorithm as described in the Draft proposes the
introduction of an additional processing step in the pipeline from
obtaining the document, parsing it and using (interpreting) it. Before
SDPng documents containing references can be used, the references have
to be resolved.
The algorithm as described works in terms of replacing elements or
transforming elements into attributes. These are not quite XML-related
features.(For example, the DOM defines the element name as a read only
attribute, which makes „replacing elements“ a non-trivial task.)

8.2 Questions

These are but some considerations about the <use> and <prop> element.
The question is how to interpret the utilization of those two elements
used for referencing:
- Should it be considered that these should be used only in terms of
referencing previously defined elements in a single SDPng message? or
- Is there some additional benefit of such reconfiguration of the SDPng
messages over the replacing algorithm?
The current SDPng Draft does not provide explanation on this problem.

Additionally, should it not be better to consider well known XML
referencing methods?

8.3 General considerations on the XML inner-document referencing

One approach to implement references is given in the XML Schema
definition language. (Globally defined) Element and type definitions can
be referenced by the usage of the “ref” attribute on the respective
elements. This approach maintains the document structure, i.e. there is
no need to change the content model of elements that may contain
references to other entities.

Typing is also stronger and validation in fact validates the document
structure as it was intended.

Processing of the document does not require another processing step,
since references are typed per se, references can be resolved in a
single step.

Customization of references is also possible. For example, attributes
and child elements given on references could be defined to override or
augment (in case the respective property was not specified in the entity
referred to) the definition.

Here is how the above sketched solution might look like:

   <def>
      <rtp:udp name="endpoint-addr-1" rtp-port="7800"
addr="224.2.0.53"/>
   </def>
   <cfg>
          <c name="interactive-audio" media="audio">
           <alt name="alt-avp-audio-10">
             <rtp:session format="rtp-avp-10">
               <rtp:udp ref="endpoint-addr-1" />
             </rtp:session>
           </alt>
         </c>
   <cfg>
______________________________________________________________

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Dirk Kutscher <[email-masked]>
Date: 27 May 2002 18:33:36 +0200

>>>>> "Teodora" == Teodora Guenkova <[email-masked]> writes:

    Teodora> Comments on Session Description and Capability Negotiation
    Teodora> Internet-Draft
    Teodora> (draft-ietf-mmusic-sdpng-04.txt)

Teodora,

thanks for your comments. Your list of inconsistencies between the
XML-Schema definition and the examples is accurate -- we have not
really updated the XML-Schema definition for -04 and validated the
examples (as we should have), so this is really helpful.

Some comments on your other remarks and questions are inline:

    Teodora> Element <sdpng:c> should be used instead of <component>
    Teodora> (This is according to the SDPng XML-schema definition),
    Teodora> as it has already been done in the rest of this document.

    Teodora> In addition, one could consider renaming <sdpng:c>
    Teodora> element to <sdpng:component> in the XML-schema. This
    Teodora> consideration corresponds a requirement from the XML 1.0
    Teodora> specification which states that XML documents should be
    Teodora> human readable and reasonably clear. The proposed change
    Teodora> or any other more informative name would enhance
    Teodora> readability of an SDPng document.

In general, I agree that human readable GIs are preferable. This is
especially important for cases where the original schema definition is
not available. However, in this case, where the schema and the
corresponding semantics are actually well documented, I felt that
abbreviating "component" with "c" could be a good idea in order to
achieve some degree of conciseness. OK, that might be a case of
"optimizing to early"... So frankly, I don't have a strong opinion on
that issue.

    Teodora> 6. Comments on the RTP-Profile definition within the SDPng XML-Schema

    Teodora> 6.1 Proposal

    Teodora> This proposal is only one of a number of possible solutions which
    Teodora> necessarily introduce minor changes to RTP Profile, while maintaining
    Teodora> required XML-side functionality, reflected in examples throughout the
    Teodora> Draft. This proposal concerns the comments on the <cfg> and the
    Teodora> <rtp:udp> elements of this document.

    Teodora> - Define element <rtp:udp> in RTP Profile as follows:

    Teodora> <xsd:element name="udp" type="rtp:UDP"
    Teodora> substitutionGroup="rtp:transport"/>

    Teodora> - Define <rtp:transport> globally in RTP Profile:

    Teodora> <xsd:element name="transport" type="rtp:Transport"
    Teodora> substitutionGroup="sdpng:d"/>

    Teodora> These two changes would allow <rtp:udp> element to be nested within
    Teodora> <def> element in an instance SDPng document. (please refer to the
    Teodora> comment on the <cfg> element above).

Yup, I will change the Schema XML-definition accordingly.

    Teodora> Furthermore, allowing <rtp:udp> element to be referenced by
    Teodora> <rtp:session> element would enable <rtp:session> to contain <rtp:udp>
    Teodora> element.

    Teodora> 6.2 Possible solution

    Teodora> Definition of complexType Session (RTP Profile) is as follows:

    Teodora> <xsd:complexType name="Session" mixed="false">
    Teodora>        <xsd:complexContent mixed="false">
    Teodora>          <xsd:extension base="sdpng:SessionConfig">
    Teodora>         <xsd:sequence>
    Teodora>          <xsd:element ref="rtp:udp" minOccurs="0"/>
    Teodora>         </xsd:sequence>
    Teodora>         <xsd:attribute name="format" type="xsd:string"/>
    Teodora>          </xsd:extension>
    Teodora>        </xsd:complexContent>
    Teodora>      </xsd:complexType>

Hmm, the basic idea here was that the definition of 'Session' requires
a child element of an abstract type ('rtp:Transport') in order to
allow for different specializations by applications and
profiles. Hence, 'rtp:udp' is just one conceivable element type that
represents a specific transport class.

Isn't it sufficient to change the defintion of 'rtp:udp' and
'rtp:transport' as you proposed and leave the definition of 'Session'
as is, i.e., require an element of type 'rtp:transport'?

    Teodora> 7. Comments on the usage of the <transport> element as attribute

    Teodora> There is no "transport" attribute defined for element
    Teodora> <rtp:session> in SDPng Base Definition, thereof no such
    Teodora> instantiation of element <rtp:session> is possible.

    Teodora> If necessary, attribute <transport> can be additionally
    Teodora> defined within complexType Session, pointing to
    Teodora> corresponding <rtp:udp> element in Definitions
    Teodora> section. Therefore, complexType Session can be rewritten
    Teodora> to include also this attribute:

Yes, true -- will be fixed.

    Teodora> However, from an XML point of view, the same
    Teodora> functionality has been already achieved by means of
    Teodora> <sdpng:use> element, thus almost eliminating the need for
    Teodora> "transport" attribute with the described properties.

I understand your argument. The reason why the 'transport' attribute
is still provided although more generic mechanisms exist, is that it
was considered useful to provide hooks for references within
profile-defined elements wherever possible: It makes the intended type
of the referenced element explicit. In addition, it also allows for
more compact definitions because you don't need to start a new
referencing element.

On the other hand I see the issue of offering two mechanisms for
referencing. For example, you need to define rules that apply in case
the definition referenced in a 'transport' attribute is overridden or
augmented by a second reference in the element content.

I would like to keep this as an open issue and have some further
discussion on it.

    Teodora> 8. Comments on the <use> and the <prop> elements

    Teodora> 8.1 Discussion

    Teodora> To summarize briefly, the <use> element proposed in section 3.3 of the
    Teodora> Draft allows flexible referencing of previously defined and named
    Teodora> entities. Additionally, using the <prop> element, these references can
    Teodora> be arbitrarily customized.

    Teodora> But there are some problems and issues with this approach.

    Teodora> a. Formal definition of the <use> and <prop> element

    Teodora> The formal definition of SDPng as given in section 5 of the Draft does
    Teodora> not provide a formal definition of the elements in question. Considering
    Teodora> the consequences of such a definition, it becomes clear that in order to
    Teodora> obtain valid documents under the employment of the <use> element, this
    Teodora> element has to be in the content model of (virtually) all elements.
    Teodora> So it would be possible to write valid documents that utilizes the <use>
    Teodora> element but it is easily imaginable that after the replacement algorithm
    Teodora> for the <use> element as described in the Draft and by  resolving all
    Teodora> references, the resulting expanded document is no longer valid under the
    Teodora> SDPng schema.
    Teodora> Since the use of the <use> element is not constrained at all – it may be
    Teodora> applied as a child under any other element and it may reference any
    Teodora> previously defined entity  (Note: references to prohibited entities are
    Teodora> thus also possible!!!).So the parser will happily parse such a document
    Teodora> and report it as valid. The resulting structure can be further applied
    Teodora> as input to the replacement algorithm, which is designed to resolve all
    Teodora> references, since  <use> elements may reference any previously defined
    Teodora> entity. As a result the replacement algorithm should be able to support
    Teodora> custom validation of the XML objects, since by applying the <use>
    Teodora> element any combination of sub-elements would be possible. This problem
    Teodora> is currently not considered in the Draft.

    Teodora> The <prop> element introduces similar problems.

True, the semantics of 'use' and 'prop' elements contradict with the
goal of having SDPng documents automatically validated on the basis of
the XML-Schema definition, especially if you try to validate the
document structure after applying any of the transformation rules.

    Teodora> 8.2 Questions

    Teodora> These are but some considerations about the <use> and <prop> element.
    Teodora> The question is how to interpret the utilization of those two elements
    Teodora> used for referencing:
    Teodora> - Should it be considered that these should be used only in terms of
    Teodora> referencing previously defined elements in a single SDPng message? or
    Teodora> - Is there some additional benefit of such reconfiguration of the SDPng
    Teodora> messages over the replacing algorithm?
    Teodora> The current SDPng Draft does not provide explanation on this problem.

The motivation here was to provide a flexible mechanism that can be
used to reference, customize and extend existing definitions. For
example, it should be possible to reference existing definitions for
video codecs and change one or two paramters without having to repeat
the whole definition.

The current proposal is therefore an attempt to maximize re-use within
documents.

The definition of the 'use' element type has been inspired by the
referencing mechanism used by the SVG specification
(http://www.w3.org/TR/SVG11/struct.html#UseElement). However, in
contrast to SVG, the schema of SDPng documents can be extended,
creating more possibilities for inconsistencies.

    Teodora> Here is how the above sketched solution might look like:

    Teodora>    <def>
    Teodora>       <rtp:udp name="endpoint-addr-1" rtp-port="7800"
    Teodora> addr="224.2.0.53"/>
    Teodora>    </def>
    Teodora>    <cfg>
    Teodora>           <c name="interactive-audio" media="audio">
    Teodora>            <alt name="alt-avp-audio-10">
    Teodora>              <rtp:session format="rtp-avp-10">
    Teodora>                <rtp:udp ref="endpoint-addr-1" />
    Teodora>              </rtp:session>
    Teodora>            </alt>
    Teodora>          </c>
    Teodora>    <cfg>

I see that this approach certainly makes things easier for DOM-based
applications and that it provides the advantage of allowing for
document validation in a sensible way.

We did not use this mechanisms because we felt that extending and
overriding referenced definitions should be more flexible, for example
by adding element content to a referenced element.

Again, let's keep this as an open issue and try to come to a decision
after some more discussion and implementation experiences.

Thanks for raising these issues!

-- 
Regards,
	Dirk

---

From: Teodora Guenkova <[email-masked]>
Date: Tue, 28 May 2002 18:50:03 +0200

Dear Dirk,
Read some comments to your comments in line.
I replaced the superfluous text with some dotted lines.
Best Regards,
        Teodora

Dirk Kutscher wrote:
....................
Dirk > Some comments on your other remarks and questions are inline:
.................................
>     Teodora> readability of an SDPng document.
Dirk > In general, I agree that human readable GIs are preferable. 
..................................................................
Dirk > OK, that might be a case of
Dirk > "optimizing to early"... So frankly, I don't have a strong
Dirk > opinion on that issue.

My remark here was really the human readability, since before
implementing a parsing application one should also without the schema
be able to understand what is the XML all about.
Scrolling to and fro between the examples and the schema of the Draft
can be a bit annoying for a first-time reader.

.......................................................
>     Teodora> 6. Comments on the RTP-Profile definition within the SDPng XML-Schema
.......................................................... 
>     Teodora> substitutionGroup="sdpng:d"/>
..........................................................
Dirk > Yup, I will change the Schema XML-definition accordingly.
...........................................................
>     Teodora>      </xsd:complexType>
............................................................. 
Dirk > Isn't it sufficient to change the defintion of 'rtp:udp' and
Dirk > 'rtp:transport' as you proposed and leave the definition of
'Session'
Dirk > as is, i.e., require an element of type 'rtp:transport'?

We were considering the examples on pages 21 to 28 of the Draft, where
the <def> element includes <rtp:udp>-element and also the usage of the
<transport> element as an attribute. 
Of course you can leave the 'Session' definition as it is, but then you
have to consider how to uniquely define a <transport> as attribute,
since having both element and attribute with the same name makes the XML
hard to interpret, especially by using SAX parsers and generating custom
objects by hand. Here I do not mean that the parsers make mistakes but
that the implementers do so and having an unique definition would make
the life of the implementers easier.
Additionally, if not having a global <transport> element definition, you 
should consider an additional local one for <def>, which can make the 
interpretation difficult as by having an attribute with the same name. 
Currently you have the <transport> element in the schema only as a 
leaf-element of the <session> element.

......................................................................

>     Teodora> 7. Comments on the usage of the <transport> element as attribute
......................................................................

Dirk > the definition referenced in a 'transport' attribute is
overridden or
Dirk > augmented by a second reference in the element content.
Dirk > I would like to keep this as an open issue and have some further
Dirk > discussion on it.
>     Teodora> 8. Comments on the <use> and the <prop> elements
...................................................................
Dirk > Again, let's keep this as an open issue and try to come to a
decision
Dirk > after some more discussion and implementation experiences.

The interpretation uniqueness was also our point by the
discussion of the <use> and <prop> elements. Our consideration concerns
also the building of a lean system with less possible components. The
additional step of de-referencing with the replacement algorithm may be
an additional source of failures and the messaging speed can also suffer
on it. 
My concern about the referencing in SDPng was really of practical
nature.

-- 
-----------------------------------------
Teodora Guenkova-Luy
Dept. Distributed Systems, University of Ulm, 
Oberer Eselsberg, 89069 Ulm, Germany

e-Mail: [email-masked] 
-----------------------------------------