Subject: [clue] comments on draft-ietf-clue-data-model-schema-07

From: Paul Kyzivat <[email-masked]>
Date: Tue, 30 Sep 2014 17:32:20 -0400

Roberta,

I tried to do a careful review of the schema again. The following are my 
notes from that:

* Terminology:

Camera-Left and Right: this is now out of date with the -17 framework.

Why has the definition of Simultaneous Transmission Set been changed to 
constrain to captures of the same type? I thought we explicitly agreed 
that there should be no such restriction.

* <mediaCaptureType>:

There is a sequence containing spatialInformation. But there are no 
bounds on it. IIUC, it should be optional - minOccurs=0, maxOccurs=1. 
(Doesn't make sense to appear more than once.)

That assumes it belongs in mediaCaptureType. While there is a single 
type for <spatialInformation>, audio and video have differing 
constraints on which parts of this may/must be present and which must 
not. ISTM that the benefit of having a single type has been lost. 
Perhaps there should just be separate spatial info types for audio and 
video.

Also, can somebody please remind me why we need an explicit notation for 
nonSpatiallyDefinable? (Rather than simply omitting spatial information.)

Similarly, is there a reason why we need "individual" as an alternative 
to to the MCC info? Couldn't we simply have MCC info as an optional fields?

The optional field element "view" of type "viewType" is confusing since 
we switched to the sceneView and globalView terminology. I think we 
should come up with a new name for this. A couple of terms that come to 
mind are: "contentType" or "subjectType".

* <personTypeType>:

I still find this, and the element "personType" of this type, to be very 
confusing to read and think about. Can we find some less confusing term 
for this? I'm tempted to suggest personRole, even though I know our past 
discussions add a lot of baggage to this. Some other terms that might 
work are: "personDuty", "personFunction", "personJob".

* Extensibility of enumerations:

This came up on the call wrt sensitivityPatternType. But there are 
several enumerations that probably have the same concern:
- personTypeType
- viewType
- presentationType
- mobilityType
- ? scaleType

The usual ietf solution for extensibility is an IANA registry. That 
would be in lieu of enumerating them in the schema. If we went that way 
then the element would probably simply be of type string, and text would 
say that the valid values are defined in a registry, and that if a value 
is not understood it should be ignored.

* <capturePointType>:

The name of this has troubled me for some time, because, once you add 
lineOfCapturePoint it is no longer a point. As an alternative, how about 
"captureOriginType"? (I don't love that, but I like it better than what 
we have and haven't thought of anything better.)

* <encodingIDListType>:

Why is the type of encID "string"? Shouldn't it be IDREF?

* <mediaCaptureIDListType>:

IIUC there is a requirement that all the captureIDREFs included in one 
list must be of the same mediaType. But this isn't stated. ISTM that 
this should be stated.

* Sample of extensibility (section 23.1):

This section says:

    The extension defines ... an
    attribute for characterizing the captures belonging to an
    "otherCaptureType" defined by the user.

 From this I infer that the recipient is expected to classify the 
predefined capture types by their type, but that extension types are to 
be classified using attributes/elements that fit within the "any" 
atttributes/elements of otherCaptureType.

Is that what is intended? It seems unnatural.

Why can't extension capture types be defined as extensions of 
mediaCaptureType, just like the builtin ones are?

* Nit - the xml schema isn't all consistently indented.

	Thanks,
	Paul