Subject: [clue] Ticket #35 consistency of data model and framework

From: "Duckworth, Mark" <[email-masked]>
Date: Fri, 12 Jul 2013 12:55:37 -0700

Here is the list of things I found to be inconsistent.

1 - data model section 3 "simultaneous capture sets" should be "simultaneous <<transmission>> sets"

2 - data model section 10 a media capture can include many spatialInformation elements.  There was some discussion of this back in November.  http://www.ietf.org/mail-archive/web/clue/current/msg02113.html.  I propose we remove the maxOccurs="unbounded" and have just a single spatialInformation, which is consistent with the framework.

3 - data model section 10.6.  The framework includes a description attribute only for a Capture Scene, while the data model includes it also for capture scene entries and media captures.  I don't recall why there is the difference.  Did the group decide we should add a description attribute to capture scene entries and media captures?

4 - data model section 10.9 should replace content element with the presentation element, as described in framework section 6.1.1.

5 - both data model and framework should add new information about role attributes/elements after discussing draft-groves-clue-role-clarifications.

6 - data model section 10.x add a "view" element as described in framework section 6.1.1

7 - data model section 10.11 rename the "dynamic" element to something like "captureMobility" and update description as described in the framework for the "Mobility of Capture" attribute.

8 - data model section 11.2 has a micPattern element, which is not in the framework.  Did the group decide to add this as an attribute of an audio capture?  I don't remember such a decision.

9 - data model section 12.1 has a nativeAspectRatio element, which is not in the framework.  Did the group decide to add this as an attribute of a video capture?  I don't remember such a decision.

10 - data model section 14.1 the sceneSpace element should be removed.  We already decided to remove the "area of scene" attribute in the framework.

11 - data model section 22 should captureEncodingType also include additional elements to specify the specific values of the parameters bandwidth, width, height, etc?  Framework section 9 says "Each Capture Encoding refers to one Media Capture, one Individual Encoding, and includes the encoding parameter values."  Refer to conversation http://www.ietf.org/mail-archive/web/clue/current/msg02526.html

Regards,
Mark

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 12 Jul 2013 17:22:42 -0400

On 7/12/13 3:55 PM, Duckworth, Mark wrote:

> 3 – data model section 10.6.  The framework includes a description
> attribute only for a Capture Scene, while the data model includes it
> also for capture scene entries and media captures.  I don’t recall why
> there is the difference.  Did the group decide we should add a
> description attribute to capture scene entries and media captures?

I thought we did for captures. Don't recall that for CSEs.

But this could be helpful for both.

	Thanks,
	Paul (as individual)

---

From: "Duckworth, Mark" <[email-masked]>
Date: Sun, 14 Jul 2013 16:56:43 -0700

I will add the description attribute to Media Capture and Capture Scene Entry in the framework, to make this consistent with the data model.

Mark

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Paul Kyzivat
> Sent: Friday, July 12, 2013 5:23 PM
> To: [email-masked]
> Subject: Re: [clue] Ticket #35 consistency of data model and framework
> 
> > 3 - data model section 10.6.  The framework includes a description
> > also for capture scene entries and media captures.  I don't recall why
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Christian Groves <[email-masked]>
Date: Mon, 15 Jul 2013 12:29:38 +1000

Hello Mark,

Please see my comments below.

Regards, Christian

On 13/07/2013 5:55 AM, Duckworth, Mark wrote:
> 1 – data model section 3 “simultaneous capture sets” should be 
> “simultaneous <<transmission>> sets”
>
> 2 – data model section 10 a media capture can include many 
> spatialInformation elements. There was some discussion of this back in 
> November. 
> http://www.ietf.org/mail-archive/web/clue/current/msg02113.html. I 
> propose we remove the maxOccurs=”unbounded” and have just a single 
> spatialInformation, which is consistent with the framework.
>
[CNG] OK
> description attribute to capture scene entries and media captures?
[CNG] I can't recall this either. I thought the idea was to describe the 
captures through attributes rather than a free text field.
>
> 4 – data model section 10.9 should replace content element with the 
> presentation element, as described in framework section 6.1.1.
>
> 5 – both data model and framework should add new information about 
> role attributes/elements after discussing 
> draft-groves-clue-role-clarifications.
>
> 6 – data model section 10.x add a “view” element as described in 
> framework section 6.1.1
>
> 7 – data model section 10.11 rename the “dynamic” element to something 
> like “captureMobility” and update description as described in the 
> framework for the “Mobility of Capture” attribute.
>
> 8 – data model section 11.2 has a micPattern element, which is not in 
> the framework. Did the group decide to add this as an attribute of an 
> audio capture? I don’t remember such a decision.
>
[CNG] Not that I'm aware of.
>
> 9 - data model section 12.1 has a nativeAspectRatio element, which is 
> not in the framework. Did the group decide to add this as an attribute 
> of a video capture? I don’t remember such a decision.
>
[CNG] Not that I'm aware of.
>
> 10 – data model section 14.1 the sceneSpace element should be removed. 
> We already decided to remove the “area of scene” attribute in the 
> framework.
>
> 11 – data model section 22 should captureEncodingType also include 
> additional elements to specify the specific values of the parameters 
> bandwidth, width, height, etc? Framework section 9 says “Each Capture 
> Encoding refers to one Media Capture, one Individual Encoding, and 
> includes the encoding parameter values.” Refer to conversation 
> http://www.ietf.org/mail-archive/web/clue/current/msg02526.html
>

[CNG] Isn't that covered by section 16 <encoding>? The structure in 22 
provides a pointer to the encoding through the encoding ID?

---

From: Roberta Presta <[email-masked]>
Date: Mon, 15 Jul 2013 21:42:36 +0200

Hi Mark,

some data model updates are listed below.
Thank you,

Roberta

Il 12/07/2013 21:55, Duckworth, Mark ha scritto:
> 1 â?? data model section 3 â??simultaneous capture setsâ?? should be 
> â??simultaneous <<transmission>> setsâ??
>
Ok.
>
> 2 â?? data model section 10 a media capture can include many 
> spatialInformation elements.  There was some discussion of this back 
> in November. 
> propose we remove the maxOccurs=â??unboundedâ?? and have just a single 
Ok.
>
> 3 â?? data model section 10.6.  The framework includes a description 
> also for capture scene entries and media captures.  I donâ??t recall 
> why there is the difference.  Did the group decide we should add a 
We left the description element in capture scene and capture scene entry.
It can be useful in the design, development and testing phases.
It appears as an optional field, however.
>
> 4 â?? data model section 10.9 should replace content element with the 
We have removed the content attribute but we have not modeled yet the 
presentation attribute by using XML Schema..
>
> 5 â?? both data model and framework should add new information about 
ToDo.
>
> 6 â?? data model section 10.x add a â??viewâ?? element as described in 
> framework section 6.1.1
>
ToDo.
>
> 7 â?? data model section 10.11 rename the â??dynamicâ?? element to 
> something like â??captureMobilityâ?? and update description as 
> described in the framework for the â??Mobility of Captureâ?? attribute.
>
Ok. We have add both an optional <mobility> element under the definition 
of the media capture type and the definition of an enumeration type 
named "mobilityType".
>
> 8 â?? data model section 11.2 has a micPattern element, which is not 
> in the framework.  Did the group decide to add this as an attribute of 
> an audio capture?  I donâ??t remember such a decision.
>
Removed - this was an example of an (optional) audio-specific media 
capture attribute that we discussed on the mailing list in a very old 
thread with John Leslie (24-10-2012).
> of a video capture?  I donâ??t remember such a decision.
>
Removed - It was a media capture attribute proposed in the Romanow's 
data model draft that we classified as a video-specific attribute.
>
> 10 â?? data model section 14.1 the sceneSpace element should be 
> removed.  We already decided to remove the â??area of sceneâ?? 
> attribute in the framework.
>
Ok.
>
> 11 â?? data model section 22 should captureEncodingType also include 
> bandwidth, width, height, etc?  Framework section 9 says â??Each 
> Capture Encoding refers to one Media Capture, one Individual Encoding, 
> and includes the encoding parameter values.â?? Refer to conversation 
Yes, given what is stated in the framework document, the 
captureEncodingType should contain both capture parameters, such as the 
selected switching policy, and encoding parameters, such as the 
bandwitdh. We provide a possible solution that needs to be further 
discussed with references to the considerations made in
http://www.ietf.org/mail-archive/web/clue/current/msg02526.html.
> [email-masked]  <mailto:[email-masked]>

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 16 Jul 2013 15:17:18 -0700

Hi Roberta,
Thanks for the updates to the data model.

<xs:sequence>
  <xs:element name="spatialInformation" type="tns:spatialInformationType"/>
</xs:sequence>

Should we remove the <xs:sequence> part now?

I added “description” attribute in the framework to be consistent with the data model.

The new “captureEncodingType” looks like a good start.
Typo:
<!-- ENCODING PARAMETERS TYPE -->
<xs:complexType name="captureParametersType">

Some “xs:integer” values were changed to bounded types (thanks!) in section 3, but not changed in the XML snippets that come later in the document.

Mark

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roberta Presta
Sent: Monday, July 15, 2013 3:43 PM
To: [email-masked]
Subject: Re: [clue] Ticket #35 consistency of data model and framework

Hi Mark,

Roberta

1 â€“ data model section 3 â€œsimultaneous capture setsâ€ should be â€œsimultaneous <<transmission>> setsâ€
Ok.

2 â€“ data model section 10 a media capture can include many spatialInformation elements.  There was some discussion of this back in November.  http://www.ietf.org/mail-archive/web/clue/current/msg02113.html.  I propose we remove the maxOccurs=â€unboundedâ€ and have just a single spatialInformation, which is consistent with the framework.
Ok.

3 â€“ data model section 10.6.  The framework includes a description attribute only for a Capture Scene, while the data model includes it also for capture scene entries and media captures.  I donâ€™t recall why there is the difference.  Did the group decide we should add a description attribute to capture scene entries and media captures?
We left the description element in capture scene and capture scene entry.
It can be useful in the design, development and testing phases.
It appears as an optional field, however.

4 â€“ data model section 10.9 should replace content element with the presentation element, as described in framework section 6.1.1.

We have removed the content attribute but we have not modeled yet the presentation attribute by using XML Schema..

5 â€“ both data model and framework should add new information about role attributes/elements after discussing draft-groves-clue-role-clarifications.

ToDo.

6 â€“ data model section 10.x add a â€œviewâ€ element as described in framework section 6.1.1

ToDo.

7 â€“ data model section 10.11 rename the â€œdynamicâ€ element to something like â€œcaptureMobilityâ€ and update description as described in the framework for the â€œMobility of Captureâ€ attribute.

Ok. We have add both an optional <mobility> element under the definition of the media capture type and the definition of an enumeration type named "mobilityType".

8 â€“ data model section 11.2 has a micPattern element, which is not in the framework.  Did the group decide to add this as an attribute of an audio capture?  I donâ€™t remember such a decision.
Removed - this was an example of an (optional) audio-specific media capture attribute that we discussed on the mailing list in a very old thread with John Leslie (24-10-2012).

9 - data model section 12.1 has a nativeAspectRatio element, which is not in the framework.  Did the group decide to add this as an attribute of a video capture?  I donâ€™t remember such a decision.
Removed - It was a media capture attribute proposed in the Romanow's data model draft that we classified as a video-specific attribute.

10 â€“ data model section 14.1 the sceneSpace element should be removed.  We already decided to remove the â€œarea of sceneâ€ attribute in the framework.
Ok.

11 â€“ data model section 22 should captureEncodingType also include additional elements to specify the specific values of the parameters bandwidth, width, height, etc?  Framework section 9 says â€œEach Capture Encoding refers to one Media Capture, one Individual Encoding, and includes the encoding parameter values.â€  Refer to conversation http://www.ietf.org/mail-archive/web/clue/current/msg02526.html

Yes, given what is stated in the framework document, the captureEncodingType should contain both capture parameters, such as the selected switching policy, and encoding parameters, such as the bandwitdh. We provide a possible solution that needs to be further discussed with references to the considerations made in
http://www.ietf.org/mail-archive/web/clue/current/msg02526.html.

Regards,
Mark

clue mailing list

[email-masked]<mailto:[email-masked]>