Subject: Re: [clue] pre-WGLC comments on data model

From: Roberta Presta <[email-masked]>
Date: Mon, 29 Sep 2014 19:26:59 +0200

Dear Mark,
thank you very much for your review.
We are about to upload version 7.
Please see below our answers.

Il 21/07/2014 16:34, Duckworth, Mark ha scritto:
>
> I thought we agreed <capturePoint> should be optional, and some text 
> and the XML for it needs to be updated.  See the previous discussion here:
>
> http://www.ietf.org/mail-archive/web/clue/current/msg03594.html
>
[RP] Capture point is now optional, both in the schema definition and in 
the textual description.
>
> >>>>> Minor Issues:
>
> Is it possible to have a media capture type that is not video or audio 
> or text?  Could it be done using just the mediaCaptureType generic 
> element?  Or would there need to be a new element type that inherits 
> from mediaCaptureType?  Is it worth mentioning this in the 
> extensibility section?
>

[RP] Actually, elements of type mediaCaptureType cannot be instantied 
since  mediaCaptureType is an abstract type.
You need to define a new type inheriting from the current 
mediaCaptureType and specializing it, as done for audioCaptureType and 
videoCaptureType.
We provide a first example of this kind of extension in the n version in 
the Extensibility section.

> <capturedMedia> element -- how about calling this something like 
> <mediaType> instead?  Would this be better as an attribute rather than 
> an element, like the "mediaType" attribute for CSE in section 15.3?
>

[RP] We changed the schema accordingly.
Please note that, when changing from version 5 to version 6, we removed 
all the mediaType attributes from scene views and encoding groups since 
they were considered unnecessary. The reason was that it is possible to 
understand the media type of such envelopes by looking at the media type 
of the first item contained in them.
In version 6 we did not append the diff section with version 5, but we 
discussed it in the IETF 90 slides:
http://www.ietf.org/proceedings/90/slides/slides-90-clue-1.pdf
This is the link to the mailing list discussion:
http://www.ietf.org/mail-archive/web/clue/current/msg03950.html ("Do we 
need the mediaType attribute if mediaType is also an attribute of the 
referenced media captures?")

> "simultaneousSetType" -- the framework says "For shorthand 
> convenience, a Provider MAY describe a Simultaneous Transmission Set 
> in terms of Capture Scene Entries and Capture Scenes".  Looks like the 
> data model allows using CSE for shorthand, but not Capture Scenes.  So 
> should there be a "sceneIDREF" element here?  Also, as Paul noted in 
> his review of the framework, there needs to be a way to identify the 
> media type for an STS if it includes only scenes.  I suggest adding a 
> <capturedMedia> (or <mediaType>) element to the simultaneousSetType, 
> with the same meaning it has elsewhere.  Then all the media captures 
> referenced in the STS must be of that media type.
>
[RP] We added both a <captureSceneIDREF> list and the mediaType 
attribute to solve the issue as Paul and you suggested.
>
> "captureEncodingType" - I agree with Christian it would be good to use 
> "mm" for millimeters in the schema.  So the scaleType would have a 
> line for enumeration value="mm" instead of value="millimeters".
>
[RP] Ok.
>
> "maxGroupBandwidth" -- I think we should specify the units for this 
> are bits per second.  The type is "xs:integer", but I think we should 
> avoid using numeric types that don't have a range limit.  How about 
> using "xs:unsignedLong" instead?
>
[RP] Ok, we changed both the schema and the description of 
<maxGroupBandwidth>.
>
> "pointType" - I think we should avoid using numeric types that don't 
> have a range limit.  How about using "xs:int" instead of 
> "xs:decimal"?  I was assuming we do not need to represent fractional 
> millimeters here, I was always assuming an int type.  If people think 
> we need to represent fractions, then should we use xs:float instead of 
> xs:decimal?
>
[RP] No problem with changing the type. We prefer xs:float instead of 
xs:decimal.
>
> "sceneEntryType" -- is the schema for this missing an attribute called 
> "mediaType"?  This is described in section 15.3, but I don't see it in 
> the schema.
>
[RP] Please see the mediaType issue above. Do you think we still need it?
>
> 10.4 paragraph 3 -- it gives switched captures as an example of non 
> spatially definable, but the framework says "For a switched capture 
> that switches between different sections within a larger area, the 
> area of capture MUST use coordinates for the larger potential area".  
> So right now this looks like a contradiction.  I think the framework 
> is correct though.
>
[RP] We removed the sentence.
>
> 10.6 <content> the text implies there must be some references to 
> captures or CSEs, but the framework says "A MCC MAY contain no 
> references to other Captures to indicate that the MCC contains content 
> from multiple sources but no information regarding those sources is 
> given."  The schema looks okay, as it has minOccurs="0" for 
> "captureIDREF" and "sceneEntryIDREF".  And it also has minOccurs="0" 
> for "content" in the media capture type in section 10.  So I think the 
> schema is fine, but the text is wrong that says this stuff is mandatory.
>
[RP] Corrected.
>
> 10.7 <synchronizationID> - "...contain at each time captures coming 
> from the same endpoint".  I think it is more flexible than the same 
> endpoint.  The framework says "It is the Provider that determines what 
> the source for the Captures is, so a Provider can choose how to group 
> together Single Media Captures for the purpose of keeping them 
> synchronized according to the SynchronisationID attribute."  The 
> provider is allowed flexibility in choosing how to switch, even when 
> it gives a syncID.  For example, the provider might decide to take 
> video streams from three separate single camera endpoints and switch 
> them together to send to a consumer that receives three video streams 
> simultaneously.
>
[RP] Corrected.
>
> audio captures -- needs to be updated for recent decisions to remove 
> audioChannelFormat, add the sensitivity pattern, and disallow area of 
> capture.
>
[RP] Done.
>
> 21 <clueInfo> - is the intent to remove this section, since an 
> advertisement is defined in the protocol document?
>
[RP] The intent is to remove this section as soon as the ADV structure 
is stably agreed, otherwise we have to modify the data model examples 
each time the ADV structure changes.

> 22 extensibility -- is there a way to extend an enumerated type to 
> include more values?
>
> >>>>> Editorial Issues:
>
> The title page says "Intended status: Informational", but I think this 
> should be Standards Track.
>
[RP] Done.
>
> 10.4 paragraph 3 "Capture of this kind are for example those related 
> to registrations..."  I'm not sure what "registrations" means here.
>
[RP] Replaced with recordings.
>
> 10.6 has (MMCC), I think this should be (MCC)
>
[RP] Done.
>
> 10.15 "refers to my means..." should be "refers to by means"
>
[RP] Done.
>
> Regards,
>
> Mark
>
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue