Subject: [clue] clue data model updates - new version available (02)

From: Roberta Presta <[email-masked]>
Date: Sat, 02 Feb 2013 18:38:51 +0100

Hi all,

we have just uploaded a new version of the data model draft.

We have added some attributes proposed in draft-groves-capture-attr-00:
- priority
- embedded text
- language
- dynamic
- language
- a new element used in place of "supplementary information" (<relatedTo>)

We have not added yet "view", "role" and "presentation". We have left 
"content" to describe the content of a capture.
It seems to us that no final consensus has been reached about all of 
them, since mail threads have been left pending.
Nonetheless, we believe the definition of keywords can help the capture 
selection process on the consumer side, but further discussion is needed 
to define them.

We have moved out from the <captureScene> blob the description of the 
available media captures again.
Indeed, media captures should have identifiers that are valid out of the 
local scope of capture scenes, since a consumer should be able to 
request also single captures in the CONFIGURE message. In each media 
capture, a reference to the capture scene containing it is provided. It 
identifies the space the spatial information of the media capture refers to.

Comments are welcome.
Cheers,

Roberta & Simon

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 02 Feb 2013 14:14:35 -0500

Hi Roberta,

Thanks for the update.

The first thing I noticed is that this version has several overly long 
lines. (idnits reports this: 
http://tools.ietf.org/idnits?url=http://tools.ietf.org/id/draft-presta-clue-data-model-schema-02.txt) 
The prior version also had long lines.

Other comments:

mediaCaptureType contains capturedMedia of type string. IIUC this is 
intended to correspond the the <media> field of the m= line in SDP. 
Valid values of this are defined in an IANA registry. So an enumerated 
type would probably be better for this, or a semantic definition that 
the value must be one of those in that registry. There might already be 
an XML definition for this somewhere. We probably also want a semantic 
restriction that this version of CLUE only supports audio and video.

I would also expect the content element to be an enumerated type, not 
just a string.

The relatedTo element contains an IDREF. But AFAICT IDREFs aren't typed, 
so what kind of entity does this refer to? Is there some way to type all 
the IDREFs so that it is syntactically clear what each refers to?

Another thing that is really a FW issue:

While it makes some sense to define captureArea with four points in 
3-space, Do don't think it makes sense to do that for sceneArea.
We expect each captureArea to be a portion of a plane, but we don't 
expect all the captures in a scene to be coplanar. (They could even be 
arranged in a circle, so that some have axes pointing in opposite 
directions.) So I think the sceneArea must describe a bounding *volume*. 
If we restrict it to being a rectangular prism then it can be defined by 
two points. or we could support arbitrary hexahedrons with eight points.

	Thanks,
	Paul (as individual)

On 2/2/13 12:38 PM, Roberta Presta wrote:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Roberta Presta <[email-masked]>
Date: Mon, 04 Feb 2013 18:17:58 +0100

Hi Paul,

sorry for the long lines (and for the multiple copies of this email), 
I'll check them in the next version.

Regarding <capturedMedia>, for the moment the simplest thing we can do
is adding  a semantic definition forcing the value of such element to
correspond to the SDP m line value.
That has been the approach adopted also in other data model RFCs (see
the XML definition of the <type> parameter in RFC4575,  A SIP event
package for conference state, which is the basis of RFC6501 about the
XCON datamodel - http://tools.ietf.org/html/rfc4575#section-5.8.2).
Alternatively, we can build an enumerative type with the options
available for SDP m lines.

As to the remaining open issues you listed, we can discuss them during
the next design team meeting.

Cheers,

Roberta

Il 02/02/2013 20:14, Paul Kyzivat ha scritto:
> the value must be one of those in that registry. There might already 
> be an XML definition for this somewhere. We probably also want a 
> semantic restriction that this version of CLUE only supports audio and 
> video.
>
> The relatedTo element contains an IDREF. But AFAICT IDREFs aren't 
> typed, so what kind of entity does this refer to? Is there some way to 
> type all the IDREFs so that it is syntactically clear what each refers 
> to?
>
> directions.) So I think the sceneArea must describe a bounding 
> *volume*. If we restrict it to being a rectangular prism then it can 
> be defined by two points. or we could support arbitrary hexahedrons 
> with eight points.
>
>     Thanks,
>     Paul (as individual)
>

---

From: Christian Groves <[email-masked]>
Date: Thu, 28 Feb 2013 17:47:23 +1100

Hello Roberta & Simon,

Obviously I support the addition of the attributes :-). 01 of my draft 
provides some updates. I see there's an agenda item for Orlando to 
discuss the capture attributes. Its probably best to align with the 
framework then.

Regards, Christian

On 3/02/2013 4:38 AM, Roberta Presta wrote:
> Nonetheless, we believe the definition of keywords can help the 
> capture selection process on the consumer side, but further discussion 
> is needed to define them.
>
> Indeed, media captures should have identifiers that are valid out of 
> the local scope of capture scenes, since a consumer should be able to 
> capture, a reference to the capture scene containing it is provided. 
> It identifies the space the spatial information of the media capture 
> refers to.
>
> Comments are welcome.
> Cheers,
>
> Roberta & Simon
>
>

---

From: Simon Pietro Romano <[email-masked]>
Date: Thu, 28 Feb 2013 11:56:16 +0100

Sure. Let's discuss this in Orlando.

Cheers,

Simon

Il giorno 28/feb/2013, alle ore 07:47, Christian Groves ha scritto:

> Hello Roberta & Simon,
> 
> Obviously I support the addition of the attributes :-). 01 of my draft provides some updates. I see there's an agenda item for Orlando to discuss the capture attributes. Its probably best to align with the framework then.
> 
> Regards, Christian
> 
>> We have not added yet "view", "role" and "presentation". We have left "content" to describe the content of a capture.
>> It seems to us that no final consensus has been reached about all of them, since mail threads have been left pending.
>> Nonetheless, we believe the definition of keywords can help the capture selection process on the consumer side, but further discussion is needed to define them.
>> 
>> We have moved out from the <captureScene> blob the description of the available media captures again.
>> Indeed, media captures should have identifiers that are valid out of the local scope of capture scenes, since a consumer should be able to request also single captures in the CONFIGURE message. In each media capture, a reference to the capture scene containing it is provided. It identifies the space the spatial information of the media capture refers to.
>> 
>> Comments are welcome.
>> Cheers,
>> 
>> Roberta & Simon
>> 
>> 

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked]

		    <<Molti mi dicono che lo scoraggiamento Ë l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/