Subject: [clue] Rob's WGLC review of draft-ietf-clue-data-model-schema-09

From: "Rob Hansen (rohanse2)" <[email-masked]>
Date: Tue, 9 Jun 2015 23:59:51 +0000

I've also been tardy on this on. No major issues found - generally a solid document.  The two things that might prompt some discussion are repeated here:

  Section 10.2
We currently say that "The "mediaType" attribute is a mandatory attribute specifying the media type of the capture ("audio", "video", "text",...)", and we have specific subsections for audio, video and text. However, for a number of elements, such as <captureArea>, that are in the generic section, whether they are mandatory, optional or not allowed are only defined for audio and video. I think their behaviour for text should be defined too (pretty much always MUST NOT be used), and we should be explicit in section 14 that new media type extensions must also define how these elements are to be used.

  Section 10.5.2.
Given that we have explicitely named the four coplanar points <bottomLeft>, <bottomRight>, <topLeft>, and <topRight>, should we mandate that they actually represent this, since otherwise someone could potentially put <bottomLeft> above <topLeft> while the far end might assume they are laid out as per their names, or should we rename them to three or four generic points that can be anything so long as they are coplanar?

Main review is as follows, in order:

  Section 2.
"...except for the "CLUE Participant" definition (which is still under discussion)" - need to remove all in-progress text before completing WGLC

The list of terms is mostly alphabetically ordered, but a few elements are out of place

"Media Captures belonging to the same Capture Scene View can be sent simultaneously by the Media Provider." - Media Captures *not* belonging to the same CSV can potentially also be sent simultaneously by the Media Provider; it's the simultaneous sets that defines simultaneity. I think the definition works fine without this line, or it should be rewritten to make clear that CSVs are intended (but not mandatory) sets of Captures.

" CLUE Participant:  This term is not imported from the framework terminology" - not sure we need to say that here (or if we do, should probably be after we've explained what it is.)

"for each encoding it is provided a set of parameters representing the encoding constraints" - grammatically this should be more like "each encoding provides a set of parameters representing the encoding constraints".

"For each group, it is provided a set of parameters representing the constraints to be applied" - as above, gramatically this should be more like "for each group, a set of parameters represent the constraints to be applied"

"Endpoint  The logical point" - should have a colon after "Endpoint"

"An endpoint consists of" - as a defined term, endpoint should probably be capitalised

"An MCU may include a Mixer." - Mixer isn't defined here; if we're going to include this line we probably need to reference another document to say what we mean by mixer (such as RFC 3550).

"is used as a synonymous of Capture Encoding." - should be something like "is used as a synonym of Capture Encoding." or "is used synonymously with Capture Encoding."

"(i.e., an Endpoint or a MCU)" - should be "an MCU"

"(i.e., an Endpoint or a MCU)" - should be "an MCU" (repeated line)

"or can appear alternatively over the time" - should be "or can appear alternatively over time"

"representing a phisical portion" - should be "representing a physical portion"

  Section 3.
"further detailed in the following of this document." - should be something like "further detailed in this document" or "further detailed later in this document"

  Section 4. (and other)
Various terms defined in the terminology section are used throughout the document but are often not capitalised.

"the list of one ore more media captures" - "ore" should be "or"

  Section 10.
"According to the CLUE framework, a media capture is" - since pretty much everything in the document is initially defined in the framework, I think saying "According to the CLUE framework" here is unnecessary; the paragraph works fine without it.

In this section, some optional elements don't define what properties are present if they are not included. We should either have a blanket statement (optional elements that don't define what their absence means means that that property is undefined) or add it for those elements.

  Section 10.2
We currently say that "The "mediaType" attribute is a mandatory attribute specifying the media type of the capture ("audio", "video", "text",...)", and we have specific subsections for audio, video and text. However, for a number of later elements, such as <captureArea>, that are in the generic section, whether they are mandatory, optional or not allowed are only defined for audio and video; whether or not these can be used for anything else (eg, text) is currently undefined. Their behaviour for text should be defined (pretty much always MUST NOT be used), and we should be explicit in section 14 that extensions must also define what to do for those elements.

  Section 10.3.
I think it would be helpful to include a link to the section that defines the capture scene ID that captureSceneIDREF is referencing

  Section 10.4.
Similarly, I think it would be helpful to include a link to the section that defines the encoding group ID that encGroupIDREF is referencing

  Section 10.5.
To avert questions, we should probably reference section 15.4 (<scale> in the capture scene) here so that people reading in order know that the units of these corrdinates are defined elsewhere.

  Section 10.5.2.
Given that we have explicitely named the four coplanar points <bottomLeft>, <bottomRight>, <topLeft>, and <topRight>, should we mandate that they actually represent this, since otherwise someone could potentially put <bottomLeft> above <topLeft> while the far end might assume they are laid out as per their names, or should we rename them to three or four generic points that can be anything so long as they are coplanar?

  Section 10.7.
"If a media capture is a MCC, then it can show in its XML data model representation the <content> element." - should be "an MCC" and I think should be "then it MAY show" to be normative.

  Section 10.8.
"MP" is used here and in a few later sections without being defined as an abbreviation of the Media Provider anywhere.

  Section 10.10.
Beyond saying that it's a string in the schema, we never define what values <policy> can take; assuming we don't plan to provide a list we should say this is a free text field, and/or that it may have values agreed between implementations or defined in later documents.

  Section 10.11.
"When the "exactNumber" attribute is set to "1"" - 'exactNumber' is defined in the schema as a boolean, so should this be 'true', not 1?

Also, I think maxCaptures should be a positiveInteger, not an unsignedInt; having 0 as a maxCaptures doesn't make any sense.

Finally, since this section is a little complicated I think an example or two may be helpful. Something like "For instance, an audio MCC "<maxCaptures>1</maxCaptures>" means that a Media Stream from the MCC will only able contain audio from a single one of its constituent captures at a time. However, <maxCaptures exactNumber="true">4</maxCaptures> would mean that the Media Stream received from the MCC will always contain a mix of audio from exactly four of its constituent captures."

  Section 10.13.
"The same element is exploited to describe, besides media captures, capture scenes and capture scene views, as it is included in their XML representation." - afraid I'm unable to follow exactly what you're saying here.

"As it can be seen" - should be something like "As can be seen".

  Section 10.14.
"When media captures are marked with a "0" priority value, it means that they are "not subject to priority"." - "not subject to priority" probably shouldn't be in quotes unless it's something defined elsewhere, and should probably be expanded on a bit.

  Section 10.16.
"static", "dynamic" and "highly dynamic" shoudl probably be in quotes, and it would be good to have a short portion explaining what each ones means

  Section 10.17.
 I think it would be helpful to include a link to the section that defines the media capture ID that relatedTo is referencing

  Section 10.20.
It's a minor detail, but should we say that the 'lang' attribute MUST NOT be used if <embeddedText> is "false" (since it makes no sense to define the language of nonexistant text)?

  Section 15.4.
""unknown" - the scale is not necessarily millimeters" - can we say "the scale is undefined" here?

  Section 16.1.
"defined as a sequence of <captureIDREF>,each containing the" - space needed after comma. And "<captureIDREF> should potentially be "<captureIDREF>s", though I'm not sure how best to pluralise XML elements.

  Section 17.1.
"expressed in bit per second" - should be "bits per second".

  Section 17.2.
<encID> has type "xs:IDREF"; should this not be "xs:ID"; I'd consider the CLUE ID to be the primary ID and SDP to reference it, but even if it were the other way around xs:IDREF has to refer to another *XML* element, does it not; it can't refer to something in SDP? It would also be useful to refer to the signalling document here to let people know what the ID association will be with.

  Section 18.
"Besides the identifiers of the captures (<mediaCaptureIDREF> elements), also the identifiers of capture scene views and of capture scene can be exploited, as shortcuts (<sceneViewIDREF> and <captureSceneIDREF> elements)." - I think this section needs to be expanded a bit to be clearer. Should probably mention that a capture may be included more than once (due to being specified by various formats) and that this has no effect different to it only appearing once.

  Section 18.1.
"When only capture scene identifiers are listed within a simultaneous set, the media type attribute MUST be used in order to determine which media captures can be simultaneously sent together." - This paragraph is repeated in Section 18.2., which is the appropriate place for it; this version should be removed.

  Section 20.1.1.
"Such identifier can be used" - I think this should be "This identifier" or "such an identifier".

Section 20.1.3.
""presenter", "timekeeper","attendee", "minute taker", "translator", "chairman", "vice-chairman"." - there should be a space after '"timekeeper",'

"A participant can play more than one conference roles." - should be "role".

  Section 21.
The capture encoding contains "captureID"s and "encodingID"s defined as xs:strings. Should these not be "captureIDREF" and "encIDREF" and be defined as xs:IDREFs, referencing the corresponding <captureID> and <encID> in the capture and encoding respectively?

  Section 21.3.
" i.e., it contains The total number of media captures listed in the <configuredContent> must be lower than or equal to the value carried within the <maxCaptures> attribute of the MCC." - "it contains" should be removed. I think the "i.e., " is probably unnecessary too; if it is left as-is the "The" should be made lower case.

  Section 22.
This should presumably be updated to match the actual protocol doc use of <advertisement> and  <configure>?
  
  Section 24.
"identified in the CLUE framework as the needed one in order to enable" - "the needed one" should be something like "necessary"

MC is used here for the first time but is never defined to be an acronym for Media Consumer.

"information incapsulated in CLUE" - "incapsulated" should be "encapsulated"

  Section 25.3.
"This section registers the " "application/clue_info+xml"" MIME type." - not sure if the double quotes is intentional; even if so, presumably having a space on one side but not the other is not.

"mechanisms such as those described in Section Security are required to protect the data" - "Section Security" should be replaced with an autonumbered section reference.

  Section 26.
"it is provided the XML representation of an endpoint-style Media Provider's offer." - "it is provided" should be "this provides" or similar.

"where the central one is also able of capturing a zoomed-out view" - "able of" should be "able to".

Rob

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 09 Jun 2015 22:57:48 -0400

These all seem like good points. (Some overlap with mine, but not 
fully.) I have a comment on one point:

> Given that we have explicitely named the four coplanar points <bottomLeft>, <bottomRight>, <topLeft>, and <topRight>, should we mandate that they actually represent this, since otherwise someone co…

It would be good to say more, but it is tricky. This can't determined 
based on the scene coordinate system, because the plane can be oriented 
in ways where that won't work. (E.g. all four points have the same 
x-coordinate - the plane is perpendicular to the "front" of the room.)

I think it has to be defined wrt the the point of capture and axis of 
capture. If the point of capture isn't specified, then the arrangement 
of these can be used to approximate an axis of capture (but not point of 
capture). Given all that, I think there are some further constraints on 
how the coordinates are arranged, but it makes my head hurt to think 
about how to define that.

	Thanks,
	Paul

---

From: Daniel Burnett <[email-masked]>
Date: Wed, 10 Jun 2015 04:20:43 -0400

Yes, solid document.  Everything of substance that I found Rob already
lists above, with the exception of the following small wording tweaks in
section 26:

2nd paragraph:  also able of -> also capable of

3rd paragraph:  such cameras -> the cameras

3rd paragraph:  capture about -> capture of

4th paragraph:  maybe 'conference roles details' -> 'conference role
details'?

-- dan

On Tue, Jun 9, 2015 at 7:59 PM, Rob Hansen (rohanse2) <[email-masked]>
wrote:

> I've also been tardy on this on. No major issues found - generally a solid
> document.  The two things that might prompt some discussion are repeated
> here:
>
>   Section 10.2
> We currently say that "The "mediaType" attribute is a mandatory attribute
> specifying the media type of the capture ("audio", "video", "text",...)",
> and we have specific subsections for audio, video and text. However, for a
> number of elements, such as <captureArea>, that are in the generic section,
> whether they are mandatory, optional or not allowed are only defined for
> audio and video. I think their behaviour for text should be defined too
> (pretty much always MUST NOT be used), and we should be explicit in section
> 14 that new media type extensions must also define how these elements are
> to be used.
>
>   Section 10.5.2.
> Given that we have explicitely named the four coplanar points
> <bottomLeft>, <bottomRight>, <topLeft>, and <topRight>, should we mandate
> that they actually represent this, since otherwise someone could
> potentially put <bottomLeft> above <topLeft> while the far end might assume
> they are laid out as per their names, or should we rename them to three or
> four generic points that can be anything so long as they are coplanar?
>
> "...except for the "CLUE Participant" definition (which is still under
> discussion)" - need to remove all in-progress text before completing WGLC
>
> "Media Captures belonging to the same Capture Scene View can be sent
> simultaneously by the Media Provider." - Media Captures *not* belonging to
> the same CSV can potentially also be sent simultaneously by the Media
> Provider; it's the simultaneous sets that defines simultaneity. I think the
> definition works fine without this line, or it should be rewritten to make
> clear that CSVs are intended (but not mandatory) sets of Captures.
>
> " CLUE Participant:  This term is not imported from the framework
> terminology" - not sure we need to say that here (or if we do, should
> probably be after we've explained what it is.)
>
> "for each encoding it is provided a set of parameters representing the
> encoding constraints" - grammatically this should be more like "each
> encoding provides a set of parameters representing the encoding
> constraints".
>
> "For each group, it is provided a set of parameters representing the
> constraints to be applied" - as above, gramatically this should be more
> like "for each group, a set of parameters represent the constraints to be
> applied"
>
> "An MCU may include a Mixer." - Mixer isn't defined here; if we're going
> to include this line we probably need to reference another document to say
> what we mean by mixer (such as RFC 3550).
>
> "is used as a synonymous of Capture Encoding." - should be something like
> "is used as a synonym of Capture Encoding." or "is used synonymously with
> Capture Encoding."
>
> "further detailed in the following of this document." - should be
> something like "further detailed in this document" or "further detailed
> later in this document"
>
>   Section 4. (and other)
> "According to the CLUE framework, a media capture is" - since pretty much
> everything in the document is initially defined in the framework, I think
> saying "According to the CLUE framework" here is unnecessary; the paragraph
> works fine without it.
>
> In this section, some optional elements don't define what properties are
> present if they are not included. We should either have a blanket statement
> (optional elements that don't define what their absence means means that
> that property is undefined) or add it for those elements.
>
>   Section 10.2
> We currently say that "The "mediaType" attribute is a mandatory attribute
> specifying the media type of the capture ("audio", "video", "text",...)",
> and we have specific subsections for audio, video and text. However, for a
> number of later elements, such as <captureArea>, that are in the generic
> section, whether they are mandatory, optional or not allowed are only
> defined for audio and video; whether or not these can be used for anything
> else (eg, text) is currently undefined. Their behaviour for text should be
> defined (pretty much always MUST NOT be used), and we should be explicit in
> section 14 that extensions must also define what to do for those elements.
>
>   Section 10.3.
> I think it would be helpful to include a link to the section that defines
> the capture scene ID that captureSceneIDREF is referencing
>
>   Section 10.4.
> Similarly, I think it would be helpful to include a link to the section
> that defines the encoding group ID that encGroupIDREF is referencing
>
>   Section 10.5.
> To avert questions, we should probably reference section 15.4 (<scale> in
> the capture scene) here so that people reading in order know that the units
> of these corrdinates are defined elsewhere.
>
>   Section 10.5.2.
> Given that we have explicitely named the four coplanar points
> <bottomLeft>, <bottomRight>, <topLeft>, and <topRight>, should we mandate
> that they actually represent this, since otherwise someone could
> potentially put <bottomLeft> above <topLeft> while the far end might assume
> they are laid out as per their names, or should we rename them to three or
> four generic points that can be anything so long as they are coplanar?
>
>   Section 10.7.
> "If a media capture is a MCC, then it can show in its XML data model
> representation the <content> element." - should be "an MCC" and I think
> should be "then it MAY show" to be normative.
>
>   Section 10.8.
> "MP" is used here and in a few later sections without being defined as an
> abbreviation of the Media Provider anywhere.
>
>   Section 10.10.
> Beyond saying that it's a string in the schema, we never define what
> values <policy> can take; assuming we don't plan to provide a list we
> should say this is a free text field, and/or that it may have values agreed
> between implementations or defined in later documents.
>
>   Section 10.11.
> "When the "exactNumber" attribute is set to "1"" - 'exactNumber' is
> defined in the schema as a boolean, so should this be 'true', not 1?
>
> Also, I think maxCaptures should be a positiveInteger, not an unsignedInt;
> having 0 as a maxCaptures doesn't make any sense.
>
> Finally, since this section is a little complicated I think an example or
> two may be helpful. Something like "For instance, an audio MCC
> "<maxCaptures>1</maxCaptures>" means that a Media Stream from the MCC will
> only able contain audio from a single one of its constituent captures at a
> time. However, <maxCaptures exactNumber="true">4</maxCaptures> would mean
> that the Media Stream received from the MCC will always contain a mix of
> audio from exactly four of its constituent captures."
>
>   Section 10.13.
> "The same element is exploited to describe, besides media captures,
> capture scenes and capture scene views, as it is included in their XML
> representation." - afraid I'm unable to follow exactly what you're saying
> here.
>
> "When media captures are marked with a "0" priority value, it means that
> they are "not subject to priority"." - "not subject to priority" probably
> shouldn't be in quotes unless it's something defined elsewhere, and should
> probably be expanded on a bit.
>
>   Section 10.16.
> "static", "dynamic" and "highly dynamic" shoudl probably be in quotes, and
> it would be good to have a short portion explaining what each ones means
>
>   Section 10.17.
>  I think it would be helpful to include a link to the section that defines
> the media capture ID that relatedTo is referencing
>
>   Section 10.20.
> It's a minor detail, but should we say that the 'lang' attribute MUST NOT
> be used if <embeddedText> is "false" (since it makes no sense to define the
> language of nonexistant text)?
>
>   Section 15.4.
> "defined as a sequence of <captureIDREF>,each containing the" - space
> needed after comma. And "<captureIDREF> should potentially be
> "<captureIDREF>s", though I'm not sure how best to pluralise XML elements.
>
>   Section 17.1.
> <encID> has type "xs:IDREF"; should this not be "xs:ID"; I'd consider the
> CLUE ID to be the primary ID and SDP to reference it, but even if it were
> the other way around xs:IDREF has to refer to another *XML* element, does
> it not; it can't refer to something in SDP? It would also be useful to
> refer to the signalling document here to let people know what the ID
> association will be with.
>
>   Section 18.
> "Besides the identifiers of the captures (<mediaCaptureIDREF> elements),
> also the identifiers of capture scene views and of capture scene can be
> exploited, as shortcuts (<sceneViewIDREF> and <captureSceneIDREF>
> elements)." - I think this section needs to be expanded a bit to be
> clearer. Should probably mention that a capture may be included more than
> once (due to being specified by various formats) and that this has no
> effect different to it only appearing once.
>
>   Section 18.1.
> "When only capture scene identifiers are listed within a simultaneous set,
> the media type attribute MUST be used in order to determine which media
> captures can be simultaneously sent together." - This paragraph is repeated
> in Section 18.2., which is the appropriate place for it; this version
> should be removed.
>
>   Section 20.1.1.
> ""presenter", "timekeeper","attendee", "minute taker", "translator",
> "chairman", "vice-chairman"." - there should be a space after
> '"timekeeper",'
>
> The capture encoding contains "captureID"s and "encodingID"s defined as
> xs:strings. Should these not be "captureIDREF" and "encIDREF" and be
> defined as xs:IDREFs, referencing the corresponding <captureID> and <encID>
> in the capture and encoding respectively?
>
>   Section 21.3.
> " i.e., it contains The total number of media captures listed in the
> <configuredContent> must be lower than or equal to the value carried within
> the <maxCaptures> attribute of the MCC." - "it contains" should be removed.
> I think the "i.e., " is probably unnecessary too; if it is left as-is the
> "The" should be made lower case.
>
>   Section 22.
> "identified in the CLUE framework as the needed one in order to enable" -
> "the needed one" should be something like "necessary"
>
> "This section registers the " "application/clue_info+xml"" MIME type." -
> not sure if the double quotes is intentional; even if so, presumably having
> a space on one side but not the other is not.
>
> "mechanisms such as those described in Section Security are required to
> protect the data" - "Section Security" should be replaced with an
> autonumbered section reference.
>
>   Section 26.
> "it is provided the XML representation of an endpoint-style Media
> Provider's offer." - "it is provided" should be "this provides" or similar.
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Robert Hansen <[email-masked]>
Date: Wed, 10 Jun 2015 12:39:44 +0100

Rather than try and force the coordinates to match the semantic meanings 
of <bottomLeft>, <bottomRight>, etc, is there a reason we can't just 
change use <point1>, <point2> and <point3>; then the only constraint we 
have to have is that none of those points may match each other or the 
point of capture - once we have more than three we have to constrain 
them to be coplanar, and once we label them as meaningful we have to 
apply those constraints to.

Rob

On 10/06/15 03:57, Paul Kyzivat wrote:
>> <bottomLeft>, <bottomRight>, <topLeft>, and <topRight>, should we 
>> mandate that they actually represent this, since otherwise someone 
>> could potentially put <bottomLeft> above <topLeft> while the far end 
>> might assume they are laid out as per their names, or should we 
>> rename them to three or four generic points that can be anything so 
>> long as they are coplanar?
>
> based on the scene coordinate system, because the plane can be 
> oriented in ways where that won't work. (E.g. all four points have the 
> same x-coordinate - the plane is perpendicular to the "front" of the 
> room.)
>
> of these can be used to approximate an axis of capture (but not point 
> of capture). Given all that, I think there are some further 
> constraints on how the coordinates are arranged, but it makes my head 
> hurt to think about how to define that.
>
>     Thanks,
>     Paul
>

---

From: Robert Hansen <[email-masked]>
Date: Wed, 10 Jun 2015 14:30:03 +0100

Sorry, this was me being stupid - forgot that we're describing the 
actual area of capture and not just the plane of interest, so we do need 
to actually define the corners.

Rob

On 10/06/15 12:39, Robert Hansen wrote:
> Rather than try and force the coordinates to match the semantic 
> meanings of <bottomLeft>, <bottomRight>, etc, is there a reason we 
> can't just change use <point1>, <point2> and <point3>; then the only 
> constraint we have to have is that none of those points may match each 
> other or the point of capture - once we have more than three we have 
> to constrain them to be coplanar, and once we label them as meaningful 
> we have to apply those constraints to.
>
> Rob
>
>> oriented in ways where that won't work. (E.g. all four points have 
>> the same x-coordinate - the plane is perpendicular to the "front" of 
>> the room.)
>>
>> capture. If the point of capture isn't specified, then the 
>> arrangement of these can be used to approximate an axis of capture 
>> (but not point of capture). Given all that, I think there are some 
>> further constraints on how the coordinates are arranged, but it makes 
>> my head hurt to think about how to define that.
>>
>>     Thanks,
>>     Paul
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Jun 2015 13:47:25 -0400

> to actually define the corners.

The variant to what you said is that we just specify points of a 
quadrilateral without any further semantics about them. But if we were 
to do that, then I think point of capture must be mandatory, not optional.

If you have the area of capture without point of capture and without any 
indication from the coordinates of how that area of capture is to be 
viewed, then you can't tell which is the front and which is the back. 
That makes a big difference!

But still, what we have seems a bit confusing and hacky, at least in 
terminology. ISTM that really what is needed for video, in addition to 
the area of capture, is info on which side is the front, and which way 
is up. (To a receiver.) The point of capture and axis of capture are 
sometimes helpful, but not mandatory. I think knowledge of which way is 
up is also sometimes needed for audio. (In addition to  (OTOH, for text 
probably the only spatial attribute of any potential relevance is point 
of capture.)

ISTM that the following spatial info is of potential use to a receiver:

Video:
- area of capture
- which side of area of capture is front
- which direction on area of capture is up
- axis of capture
- point of capture

Audio:
- axis of capture
- point (or points) of capture
- pattern

Text:
- point of capture

As things stand, you can potentially infer which side of the area of 
capture is front, and which way is up, from the coordinates of the area 
of capture, given what the names of the four corners imply. But this 
could be confusing to some if they receive and adv where numerically the 
left coordinates are greater than the right coordinates.

It might be better to allow all of these things to be explicitly 
specified. (We could then still define how to derive defaults for some 
of them. E.g. that the default axis of capture is normal to the center 
of the area of capture.)

	Thanks,
	Paul

---

From: "Duckworth, Mark" <[email-masked]>
Date: Tue, 16 Jun 2015 15:10:29 -0700

I think it is simple.  The four points of the area of capture define left, right, top, bottom from the point of view of somebody looking at it, even if the point of capture is not given.  We could add a sentence in the data model to say this.

Mark

> -----Original Message-----
> From: clue [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> Sent: Wednesday, June 10, 2015 1:47 PM
> To: [email-masked]
> Subject: Re: [clue] Rob's WGLC review of draft-ietf-clue-data-model-schema-
> 09
>

---

From: Christian Groves <[email-masked]>
Date: Wed, 17 Jun 2015 14:59:14 +1000

I agree with Mark here.

Christian

---

From: Simon Pietro Romano <[email-masked]>
Date: Mon, 29 Jun 2015 18:56:55 +0200

Hi Bob,

thanks a lot for your thorough review!

See in-line ([SPR]) for some comments and replies…

> We currently say that "The "mediaType" attribute is a mandatory attribute specifying the media type of the capture ("audio", "video", "text",...)", and we have specific subsections for audio, video…

[SPR] OK. We modified the draft accordingly.

> Given that we have explicitely named the four coplanar points <bottomLeft>, <bottomRight>, <topLeft>, and <topRight>, should we mandate that they actually represent this, since otherwise someone co…

[SPR] This has already been discussed (and solved) on the ML. The document is in-line with what has been agreed upon in that thread.

> "...except for the "CLUE Participant" definition (which is still under discussion)" - need to remove all in-progress text before completing WGLC

[SPR] Done. No in-progress text should be now present in the document.

> The list of terms is mostly alphabetically ordered, but a few elements are out of place

[SPR] Done. Definitions have been properly sorted.

> "representing a phisical portion" - should be "representing a physical portion”

[SPR] All definitions in section 2 have been copy-pasted from the latest framework document.

>  Section 3.
> "further detailed in the following of this document." - should be something like "further detailed in this document" or "further detailed later in this document”

[SPR] Done.

> Various terms defined in the terminology section are used throughout the document but are often not capitalised.

[SPR] Done.

> 
> "the list of one ore more media captures" - "ore" should be “or"

[SPR] Done.

> "According to the CLUE framework, a media capture is" - since pretty much everything in the document is initially defined in the framework, I think saying "According to the CLUE framework" here is…

[SPR] Agreed.

> In this section, some optional elements don't define what properties are present if they are not included. We should either have a blanket statement (optional elements that don't define what their…

[SPR] Blanket statement added.

> We currently say that "The "mediaType" attribute is a mandatory attribute specifying the media type of the capture ("audio", "video", "text",...)", and we have specific subsections for audio, video…

[SPR] See above…

> I think it would be helpful to include a link to the section that defines the capture scene ID that captureSceneIDREF is referencing

[SPR] Done.

> Similarly, I think it would be helpful to include a link to the section that defines the encoding group ID that encGroupIDREF is referencing

[SPR] Done.

> To avert questions, we should probably reference section 15.4 (<scale> in the capture scene) here so that people reading in order know that the units of these corrdinates are defined elsewhere.

[SPR] Done.

> Given that we have explicitely named the four coplanar points <bottomLeft>, <bottomRight>, <topLeft>, and <topRight>, should we mandate that they actually represent this, since otherwise someone co…

[SPR] Done. See above…

> "If a media capture is a MCC, then it can show in its XML data model representation the <content> element." - should be "an MCC" and I think should be "then it MAY show" to be normative.

[SPR] Done.

> "MP" is used here and in a few later sections without being defined as an abbreviation of the Media Provider anywhere.

[SPR] Done. Expanded everywhere.

> Beyond saying that it's a string in the schema, we never define what values <policy> can take; assuming we don't plan to provide a list we should say this is a free text field, and/or that it may h…

[SPR] Done. We added a proper schema definition for policies.

> "When the "exactNumber" attribute is set to "1"" - 'exactNumber' is defined in the schema as a boolean, so should this be 'true', not 1?

[SPR] Right. Modified accordingly.

> Also, I think maxCaptures should be a positiveInteger, not an unsignedInt; having 0 as a maxCaptures doesn't make any sense.

[SPR] Right. Modified accordingly.

> Finally, since this section is a little complicated I think an example or two may be helpful. Something like "For instance, an audio MCC "<maxCaptures>1</maxCaptures>" means that a Media Stream from the MCC will only able contain audio from a single one of its constituent captures at a time. However, <maxCaptures exactNumber="true">4</maxCaptures> would mean that the Media Stream received from the MCC will always contain a mix of audio from exactly four of its constituent captures.”

[SPR] Done. Example added.

> "The same element is exploited to describe, besides media captures, capture scenes and capture scene views, as it is included in their XML representation." - afraid I'm unable to follow exactly wha…

[SPR] The definition has been properly modified. There should be no inconsistencies in the document in its current version.

> "As it can be seen" - should be something like "As can be seen”.

[SPR] Done

> "When media captures are marked with a "0" priority value, it means that they are "not subject to priority"." - "not subject to priority" probably shouldn't be in quotes unless it's something defin…

[SPR] Done.

> "static", "dynamic" and "highly dynamic" shoudl probably be in quotes, and it would be good to have a short portion explaining what each ones means

[SPR] Done. The short portion has been extracted from the framework document.

> I think it would be helpful to include a link to the section that defines the media capture ID that relatedTo is referencing

[SPR] Done.

> It's a minor detail, but should we say that the 'lang' attribute MUST NOT be used if <embeddedText> is "false" (since it makes no sense to define the language of nonexistant text)?

[SPR]  Indeed, 'lang’  is not the language of the <embeddedText> element (this seems to be also in line with what stated in the framework). In our interpretation, “lang” is associated with the language(s) that are ‘spoken’ in a specified media capture. Correct us if we’re wrong...

> ""unknown" - the scale is not necessarily millimeters" - can we say "the scale is undefined" here?

[SPR] OK. 
 
> "defined as a sequence of <captureIDREF>,each containing the" - space needed after comma. And "<captureIDREF> should potentially be "<captureIDREF>s", though I'm not sure how best to pluralise XML…

[SPR] OK.

>  Section 17.1.
> "expressed in bit per second" - should be "bits per second”.

[SPR] OK

> <encID> has type "xs:IDREF"; should this not be "xs:ID"; I'd consider the CLUE ID to be the primary ID and SDP to reference it, but even if it were the other way around xs:IDREF has to refer to ano…

[SPR] It should actually be a simple string (the same encoding can actually appear in multiple encoding groups). It used to be an IDREF before, because in previous versions of the schema we had a dedicated element associated with each and every “individual" encoding. 

> "Besides the identifiers of the captures (<mediaCaptureIDREF> elements), also the identifiers of capture scene views and of capture scene can be exploited, as shortcuts (<sceneViewIDREF> and <captu…

[SPR] Done.

> "When only capture scene identifiers are listed within a simultaneous set, the media type attribute MUST be used in order to determine which media captures can be simultaneously sent together." - T…

[SPR] Done.

>  Section 20.1.1.
> "Such identifier can be used" - I think this should be "This identifier" or "such an identifier”.

[SPR] Done.

> Section 20.1.3.
> ""presenter", "timekeeper","attendee", "minute taker", "translator", "chairman", "vice-chairman"." - there should be a space after '"timekeeper”,'

[SPR] Done.

> "A participant can play more than one conference roles." - should be "role”.

[SPR] Done.

> The capture encoding contains "captureID"s and "encodingID"s defined as xs:strings. Should these not be "captureIDREF" and "encIDREF" and be defined as xs:IDREFs, referencing the corresponding <cap…

[SPR] <captureEncoding> elements are conceived to be contained in CONFIGURE messages and hence refer to information extracted from a different XML document, namely the ADVERTISEMENT message. They cannot hence be IDREFs.

> " i.e., it contains The total number of media captures listed in the <configuredContent> must be lower than or equal to the value carried within the <maxCaptures> attribute of the MCC." - "it conta…

[SPR] Done.

> This should presumably be updated to match the actual protocol doc use of <advertisement> and  <configure>?

[SPR] Done.

> "identified in the CLUE framework as the needed one in order to enable" - "the needed one" should be something like “necessary”

[SPR] Done.

> MC is used here for the first time but is never defined to be an acronym for Media Consumer.

[SPR] Done. Expanded everywhere.

> "information incapsulated in CLUE" - "incapsulated" should be “encapsulated"

[SPR] Corrected.

> "This section registers the " "application/clue_info+xml"" MIME type." - not sure if the double quotes is intentional; even if so, presumably having a space on one side but not the other is not.

[SPR] Quotes removed.

> "mechanisms such as those described in Section Security are required to protect the data" - "Section Security" should be replaced with an autonumbered section reference.

[SPR] Done.

> "it is provided the XML representation of an endpoint-style Media Provider's offer." - "it is provided" should be "this provides" or similar.

[SPR] Done.

> "where the central one is also able of capturing a zoomed-out view" - "able of" should be "able to”.

[SPR] Modified.

Thanx 1k again,

Simon & Roberta

> Rob

                     					       _\\|//_
                           				      ( 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~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/

----
5x1000 AI GIOVANI RICERCATORI
DELL'UNIVERSITÀ DI NAPOLI
Codice Fiscale: 00876220633
www.unina.it/Vademecum5permille