Re: [siprec] draft-ram-siprec-metadata-format-01

Here is some feedback on draft-ram-siprec-metadata-format-01. 

In the xml schema, the group is not listed as an element in the sequence for the recording-metadata, which conflicts with the example in 5.1.

In addition, I found it confusing that the extension data is included in the participant type but not included in any of the other defined elements in the recording-metadata. I think it might be good idea to include the extension data as last element in the sequences for the group, session, etc. As that would eliminate the need for the parent attribute in the extension data assuming it stays close to its current format.

Regards,
   Scott

-----Original Message-----
From: siprec-bounces@ietf.org [mailto:siprec-bounces@ietf.org] On Behalf Of Paul Kyzivat
Sent: Thursday, March 31, 2011 7:19 AM
To: Peter Saint-Andre
Cc: siprec@ietf.org
Subject: Re: [siprec] draft-ram-siprec-metadata-format-01

On 3/31/2011 5:06 AM, Peter Saint-Andre wrote:
> I am booked through 11 PM tonight.
>
> Tomorrow I have the following windows of time:
>
> 07:00-07:30
> 15:15-16:00
>
> Naturally that time might get filled if issues come up in some of my
> working groups. :)

But you also have 11-12pm tonite? :-)
(That is much better for me than the others.)

Maybe its just too late in the week to hope for this.
We can take it to the list.

	Thanks,
	Paul

> On 3/31/11 10:55 AM, Paul Kyzivat wrote:
>> Peter/Joe,
>>
>> Do either of you have any time in the remainder of the week when some of
>> us could sit and try to sort out the right way to do the extension data?
>> I doubt it would take very long.
>>
>>      Thanks,
>>      Paul
>>
>> On 3/30/2011 6:25 PM, Peter Saint-Andre wrote:
>>> Here is some quick feedback on draft-ram-siprec-metadata-format-01. I
>>> hope to review it more fully soon.
>>>
>>> 1. I would change application/recording to application/recording+xml in
>>> accordance with RFC 3023 (many specs illustrate the use of XML media
>>> types -- see for example RFC 4287).
>>>
>>> 2. The large number of<extensiondata/>   elements is a bit confusing in
>>> the examples.
>>>
>>> 3. In Section 5.1, the example has one<extensiondata/>   element
>>> qualified by the 'urn:ietf:params:xml:ns:siprec' namespace (no other
>>> namespace is defined) and then multiple<extensiondata/>   elements
>>> qualified by other namespaces ('http://example.com/groupapp',
>>> 'http://example.com/sessionapp', etc.). Although those other namespaces
>>> are certainly *allowed* to use "extensiondata" as an element name
>>> (that's the beauty of namespaces), it is confusing in this document.
>>> Perhaps you even meant to have<extensiondata/>   elements qualified by
>>> the 'urn:ietf:params:xml:ns:siprec' and then child elements qualified by
>>> other namespaces (in accordance with the schema). However, that is not
>>> clear in the spec.
>>>
>>> 4. There is no built-in datatype for xs:urnuuid, xs:streamMode,
>>> xs:requester, and so on. See W3C XML Schema Part 2:
>>>
>>>      http://www.w3.org/TR/xmlschema-2/#built-in-datatypes
>>>
>>> 5. The data in the<name/>   elements with xml:lang="it" really should be
>>> Giulietta Capuleti and Romeo Montecchi. ;-)
>>>
>>> Peter
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> siprec mailing list
>>> siprec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/siprec
>> _______________________________________________
>> siprec mailing list
>> siprec@ietf.org
>> https://www.ietf.org/mailman/listinfo/siprec
>
>
_______________________________________________
siprec mailing list
siprec@ietf.org
https://www.ietf.org/mailman/listinfo/siprec