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

From: "Duckworth, Mark" <[email-masked]>
Date: Mon, 21 Jul 2014 07:34:25 -0700

Comments on draft-ietf-clue-data-model-schema-06

Overall it is very good.  I have mostly minor and editorial suggestions.  There are still a few recent changes in the framework, and possible more coming, which we need to keep up to date in the data model.  This set of comments includes questions I raised in my email on June 27.

>>>>> Major Issues:

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

>>>>> 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?

<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?

"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.

"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".

"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?

"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?

"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.

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.

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.

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.

audio captures - needs to be updated for recent decisions to remove audioChannelFormat, add the sensitivity pattern, and disallow area of capture.

21 <clueInfo> - is the intent to remove this section, since an advertisement is defined in the protocol document?

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.

10.4 paragraph 3 "Capture of this kind are for example those related to registrations..."  I'm not sure what "registrations" means here.

10.6 has (MMCC), I think this should be (MCC)

10.15 "refers to my means..." should be "refers to by means"

Regards,
Mark