Hi Roberta,
Yes, your example illustrates a case like I was talking about, where it is useful to have <captureArea> without <capturePoint>.

Mark

> -----Original Message-----
> From: Roberta Presta [mailto:roberta.presta@unina.it]
> Sent: Wednesday, March 26, 2014 1:03 PM
> To: Duckworth, Mark
> Cc: John Leslie; clue@ietf.org; Christian Groves
> (Christian.Groves@nteczone.com)
> Subject: Re: [clue] <capturePoint> should be optional
> 
> Ok Mark,
> 
> I see your point thanks to the scenario you have described.
> I will change the definitions provided in the data model accordingly.
> 
> For the case you have proposed, the ADV could be the following:
> 
> capture scene A: captures coming from room A capture scene B: captures
> coming from room B capture scene C: captures coming from room C capture
> scene D: MCC A (from room A's captures) - to be rendered on the left, MCC B
> (from room B's captures) - to be rendered on the centre, MCC C (from room
> C's capture) - to be rendered on the right
> 
> where the "to be rendered" information are represented by means of the
> <capturedArea> within the <spatialInformation> tag associated to the MCCs.
> 
> Could that be a correct solution?
> 
> Roberta
> 
> 
> 
> Il 26/03/2014 17:09, Duckworth, Mark ha scritto:
> > Hi Roberta and John,
> >
> > I disagree that <capturePoint> should be required within
> <spatialInformation>.  I think Christian shares this view.
> > I also disagree with this from section 10.4:
> > "Captures are spatially definible when it is possible to provide at
> > least the coordinates of the device position within the telepresence
> > room of origin."
> >
> > I suggest changing it to:
> > "Captures are spatially definable when it is possible to provide the
> > coordinates of either the device position or the area of capture
> > within the telepresence room of origin."
> >
> > The intent (in the framework, at least) was to allow a provider to specify
> "area of capture" but not specify "point of capture" for any particular media
> capture.  I think we unintentionally lost this possibility when we moved some
> attribute details from the framework to the data model several revisions ago.
> >
> > One example scenario where this makes sense is in an advertisement from
> an MCU that is constructing MCCs for its own scene, and will fill it by
> composing and/or switching captures from other endpoints.  The MCU can
> specify "area of capture" using "no scale" coordinates (e.g. to maintain
> consistent left-to-right relationship), but in this case a "point of capture" is
> not useful, not meaningful, and should not be required.
> >
> > Mark
> >
> >> -----Original Message-----
> >> From: Roberta Presta [mailto:roberta.presta@unina.it]
> >> Sent: Wednesday, March 26, 2014 5:16 AM
> >> To: Duckworth, Mark
> >> Cc: John Leslie; clue@ietf.org
> >> Subject: Re: [clue] <capturePoint> should be optional
> >>
> >> Hi Mark,
> >>
> >> I have seen the previous messages but have not forwarded my (very
> >> late) reply since I have tried to be clearer in the new data model text.
> >> The current specification of the data model is compatible with the
> >> following
> >> statement:
> >> "If the point of capture is not specified, it means  the consumer
> >> should not assume anything about the spatial location of the capturing
> device."
> >> Indeed, when describing a media capture, you have two possibilities
> >> (for the "choice" implementation):
> >> - if a capture is not spatially definable, it will not have any
> >> <spatialInformation> within its description and it will have a
> >> <nonSpatiallyDefinible> tag set to true.
> >> - otherwise (spatially definable capture), at least the capture point
> >> should be provided within the <spatialInformation> tag. Other
> >> information, like the line of capture point and the captured area, are
> optional.
> >> I think that John shares my view.
> >> Does it sound to you (all)?
> >>
> >> Roberta
> >>
> >>
> >> Il 26/03/2014 01:11, John Leslie ha scritto:
> >>> Duckworth, Mark <Mark.Duckworth@polycom.com> wrote:
> >>>> There still seems to be a mistake in the data model about
> >>>> <capturePoint> being mandatory, when it should be optional.  Please
> >>>> see
> >> below.
> >>>> ...
> >>>      I'm not at all sure I understand this discussion.
> >>>
> >>>      ISTM that spatialInformationType is included as a possible
> >>> entry in items where it is usually meaningless...
> >>>
> >>>      But I am confused by the discussion of capturePoint being
> >>> optional within spatialInformationType.
> >>>
> >>>      What is the meaning of an instance of spatialInformationType
> >>> without a capturePoint?
> >>>
> >>> --
> >>> John Leslie <john@jlc.net>
> >>>
> >