 – where is type language defined? I did not see it in =
http://www.w3.org/2001/XMLSchema<=
/pre> 

Roni

From: clue [mailto:clue-bounces@ietf.org] On Behalf Of Roberta =
Presta
Sent: 23 June, 2015 1:55 PM
To: =
clue@ietf.org
Subject: Re: [clue] Paul's WGLC review of =
draft-ietf-clue-data-model-schema-09

Dear all, =
we are =
applying the modifications derived by your comments.
These are the =
first ones coming from Paul's review.
We considered also Mark's reply =
to Paul to answer as in the =
following.
Regards,

Roberta

Il 09/06/2015 21:54, =
Paul Kyzivat ha scritto:
I'm sorry for being so tardy in providing =
a review of this document. I just now went through it: 

* Section =
2: 

Capture Device: says it converts audio and video. Should =
probably also mention text. 

OK. =
Definition replaced with the one in the =
framework.

MCC: I can't quite make sense of the this =
part: "... the Stream coming from the encoding of the composing =
Media Captures ...". I *think* the intent can be achieved by =
replacing that with "... the contained media captures ...". =

OK. Replaced with "contained media =
captures”.

Spatial =
Information: s/generate/generates/, s/phisical/physical/ =

OK.

* Section 3: 

General: I'm not =
an xml expert. I see odds and ends of formatting idiosyncracies that =
seem odd to me, though clearly simply editor choices. I will not mention =
those. It might be good for somebody who isn't an author but is an XML =
expert to review the schema for style. Or perhaps it can be run through =
an XML pretty-printer. 

OK.

In the following: 

   =
The element and attribute definitions are formal representations of =

   the concepts needed to describe the capabilities of a =
Media Provider 
   and the streams that are requested by a =
Media Consumer given the 
   Media Provider's ADVERTISEMENT =
([I-D.ietf-clue-protocol]). 

s/requested/available to be =
requested/ 

I left =
"are requested" since the intention was the one detected by =
Mark in answering Paul's review.
("[Duckworth, Mark] I thought =
it was referring to a Consumer's configure message, so it would be the =
streams requested by a consumer.")

Policy for MCCs: is =
just a string. How are we going to specify the available policies? =

OK. We added a regular =
expression to define the content of the <policy> element in the =
form of "token:index".

<xs:simpleType =
name=3D"policyType">
 <xs:restriction =
base=3D"xs:string">
      =
<xs:pattern =
value=3D"([a-zA-Z0-9])+[:]([0-9])+"/>
    =
</xs:restriction>
</xs:simpleType>

<=
/p>
MEDIA CAPTURE =
TYPE: Language is currently optional, but with max of one. Shouldn't =
multiple languages be allowed? 

OK. =
XML Schema definition updated =
(maxOccurs=3D"unbounded”).

MEDIA CAPTURE TYPE: "mediaType" =
is just a string. How are we going to specify the available media types? =

As highlighted by Mark, it is defined in section 10.2 =
of the document. Audio, video and text are just examples of valid media =
types. We did  not want to put any constraints on the set of =
possible media types.

PERSON TYPE: I know we discussed this =
before, but I still find it disturbing that we have a complexType named =
"personType" that contains an element named =
"personType". I guess it is syntactically and semantically =
well defined, but it is certainly confusing to read the schema. I would =
expect to get confusion in the future. I suggest replacing =
personTypeType with personRoleType or personJobType or personDutyType, =
and then change the element name to match. (I recall there were reasons =
not to use Role.) 

I am =
OK with any change (e.g., from <personType> to =
<personRole>), but the Framework document should be changed =
accordingly. Our preferred option is to leave things as they are, =
btw.

SPATIAL INFORMATION TYPE: Syntactically =
this allows you to provide spatial information yet omit both the =
capturePoint and the captureArea. IIUC it is an error to specify =
neither. (Should have then specified non-spatially-defined.) Can the XML =
be structured to prevent this misuse? 

This =
is actually specified in the text, rather than formally specified in the =
XML schema.

MOBILITY TYPE: having "dynamic" and =
"highly-dynamic" seems confusing. How about =
"variable" and "dynamic"? 

This is indeed how mobility type has been defined =
in the Framework document. We’re OK with modifying such a =
definition, but framework should be changed =
accordingly.

  =
OTHER =
CAPTURE TYPE: why doesn't this look exactly like TEXT CAPTURE TYPE? (It =
differs by omission of anyAttribute.) 

Actually, they do look identical in the current =
version of the document.

CAPTURE POINT TYPE: it still seems odd to =
me to call this a *point* when it actually can define a vector. How =
about "captureVector"? Or, since the part that makes it a =
vector is optional, maybe "captureOrigin". =

I am OK with captureOrigin. Does everybody =
agree?

ENCODING ID LIST TYPE: this defined =
encID. Presumably this is intended to refer to the =
"encodingID" elementof captureEncodingType. Is that =
correspondence specified somewhere? Is there a reason not to use the =
IDREF mechanism? (Does the idref only work in a single document, while =
this needs to work from a configure toward an advertisement?) =

Actually, in the definition of <encodingIDList>, =
the type of <encID> is IDREF.

* Section 10.1: =

It would be helpful to say that the captureID serves as the way =
the capture is referenced from CaptureEncodings created by the consumer =
in Configure messages. 

OK. =
Text added.

* Section 10.5.2: 

It would be =
helpful to note that the capture area has two "sides", and it =
implies which side is the "front". (The capture point must be =
on the side from which it is possible to view the left points as left of =
the right points, and the top points as above the bottom points.) =

OK, we added: "The four coplanar points are =
identified from the perspective of the capture =
device.”

* Section 10.8: 

This says =
"... captures coming from the same source." But I think it is =
possible for switching to include multiple sources concurrently. So I =
think that needs to be changed to "... same sources.". =

OK.

Also, in this section what is =
"MP"? I guess it means Media Provider? Either this should be =
added to the definitions, or it should be expanded. (Note that this is =
also used elsewhere.) 

OK. =
Expanded everywhere.

* Section 10.16: 

It would be good =
to specify the semantics attaching to each value. I.e.: 

static: =
SHOULD not change for the duration of the CLUE session, across multiple =
advertisements. 

dynamic: MAY change in each new advertisement. =
Can be assumed to remain unchanged until there is a new advertisement. =

highly-dynamic: MAY change dynamically, even between =
advertisements. The value in an advertisement is simply a snapshot of =
the location at the time of the advertisement. 

OK. =
Text added.

* Section 21: 

While this may =
repeat the framework, I think this section should explain the the =
references in the captureEncoding are to captures and encodings defined =
in a separate XML document (an advertisement). 

OK. =
Done.

* Section 22: 

What is "a =
drafty version" intended to mean??? 

Replaced with:
The <clueInfo> element =
includes all the information needed to represent the Media Provider's =
description of its telepresence capabilities according to the CLUE =
framework (i.e., it actually represents the body of the ADVERTISEMENT =
message). 
  =

    Thanks, =

    Paul =

_______________________________________________ 
clue mailing =
list 
clue@ietf.org 
https://www.ietf.org/=
mailman/listinfo/clue 

----
5x100=
0 AI GIOVANI RICERCATORI
DELL'UNIVERSITA' DI NAPOLI
Codice =
Fiscale: 00876220633
www.unina.it/Vademecum5permille
    =