Subject: Re: [clue] again on <spatialInformation>

From: Paul Kyzivat <[email-masked]>
Date: Thu, 01 Nov 2012 12:57:07 -0400

On 10/31/12 6:42 AM, Roberta Presta wrote:
> Hi Paul,
>
> I don't see any problem in putting media captures inside capture scenes and delete the <mediaCaptures> section under <clueInfo>.
> The sceneIDREF attribute of <spatialInformation> does not need to exist anymore, since the coordinate space would be the one of the involving capture scene.

WFM

> The remaining point now is the new definition of the media capture type, which presents the <choice> section that allows to contain spatial information or,
> alternatively, to mark the media capture as "non spatially definible".
> What do you think about that proposal?

I'm ok with it.

> I copy below the schema snapshot for convenience.
>
> Cheers,
>
> Roberta
>
>
>       <!-- MEDIA CAPTURE TYPE -->
>       <xs:complexType name="mediaCaptureType" abstract="true">
>          <xs:sequence>
>           <xs:element name="description" type="xs:string" minOccurs="0"/>
>           <xs:element name="capturedMedia" type="xs:string" minOccurs="0"/>
>           <xs:element name="encGroupIDREF" type="xs:IDREF"/>
>           <xs:element name="content" type="xs:string" minOccurs="0"/>
>           <xs:element name="switched" type="xs:boolean" minOccurs="0"/>
>           <xs:element name="composed" type="xs:boolean" minOccurs="0"/>                                   	
>           <xs:element name="maxCaptureEncodings" type="xs:unsignedInt" minOccurs="0"/>
>           <xs:choice>
>               <xs:sequence>
>                <xs:element name="spatialInformation" type="tns:spatialInformationType" maxOccurs="unbounded"/>
>              </xs:sequence>             	
>           	<xs:element name="nonSpatiallyDefinible" type="xs:boolean" fixed="true"/>         		
>           </xs:choice>

I'm an xml lightweight. In the above, why isn't it just:

<xs:choice>
   <xs:element name="spatialInformation"
               type="tns:spatialInformationType" maxOccurs="unbounded"/>
   <xs:element name="nonSpatiallyDefinible"
               type="xs:boolean" fixed="true"/>         		
</xs:choice>

What do the <sequence>s add?

	Thanks,
	Paul

>           <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
>          </xs:sequence>
>          <xs:attribute name="captureID" type="xs:ID" use="required"/>
>          <xs:anyAttribute namespace="##other" processContents="lax"/>
>       </xs:complexType>
>
>       <!-- SPATIAL INFORMATION TYPE -->
>       <xs:complexType name="spatialInformationType">
>       <xs:sequence>
>         <xs:element name="capturePoint" type="capturePointType"/>
>         <xs:element name="captureArea" type="captureAreaType" minOccurs="0"/>
>         <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
>        </xs:sequence>
>         <xs:anyAttribute namespace="##other" processContents="lax"/>
>       </xs:complexType>
>
>
>
>
>
>
>
>
>
>   ----------------------
>
> Roberta,
>
> I don't see how this addresses the problem. I think I see why. Comment
> inline
>
> On 10/26/12 6:13 AM, Roberta Presta wrote:
> [snip]
>
>     * The <spatialInformation> element is referred to the coordinate space
>     of the capture scene indicated in the "sceneIDREF" attribute.
>     The framework doesn't seem to force a capture to be associated with only
>     one scene (or, at least, I don't remember to have read such a constraint
>     in the framework document).
>     If a capture is involved in more than one scene, more than one
>     <spatialInformation> should be provided, each one related to the
>     coordinate space of the involving scene.
>
>
>
> Whether clear or not, IMO it is *intended* that each capture is
> associated (belongs to) a single scene. ISTM an obvious way to represent
> this would be to have an instance of mediaCapturesType within
> captureSceneType, rather than within clueInfoType.
>
> Thanks,
>
> Paul
>
>
>
>

---

From: Roberta Presta <[email-masked]>
Date: Fri, 02 Nov 2012 11:32:01 +0100

Hi Paul,

putting the <spatialInformation> element inside <sequence> with 
maxOccurs="unbounded" means that you can find more than one 
<spatialInformation> describing a capture.
Using a definition without <sequence>, on the other hand, means that you 
can find only one <spatialInformation> describing a capture. The 
definition would look like the following:

<xs:choice>
   <xs:element name="spatialInformation"
               type="tns:spatialInformationType"/>
   <xs:element name="nonSpatiallyDefinible"
               type="xs:boolean" fixed="true"/>
</xs:choice>

The current definition (the one with <sequence>) leaves open the 
possibility of specifying more than one <spatialInformation> for a 
capture.  That chance could be exploited in case of composed capture to 
describe spatially each component  by adding  a <spatialInformation> 
element for each of them (I don't know if it could be really useful, I 
have left the definition "as is" to the aim of discussing about it).

Alternatively, we can decide that only one <spatialInformation> can be 
provided for a capture.
In case of composed capture that are also spatially definible, the 
single <spatialInformation> element would carry the information of the 
maximum captured space.
In that case, the XML Schema definition would remove the <sequence> 
envelope and the maxOccurs="unbounded" attribute, as reported above.

What is the option that makes more sense to you?

Cheers,

Roberta

---

From: Simon Pietro Romano <[email-masked]>
Date: Fri, 02 Nov 2012 12:33:36 +0100

Dear all,

waiting for I-D submissions to re-open, I have temporarily published the 
new version of the clue data model schema on the following site:

http://www.grid.unina.it/Didattica/RetiDiCalcolatori/inf/draft-presta-clue-data-model-schema-02.html

  I hope this proves useful for those who want to have fresh information 
at the upcoming CLUE session on Monday. The file contains the updated 
version of the schema (which tries to adhere to the latest discussions), 
as well as a sample XML file compliant with the proposed schema.

Cheers,

Simon

Il 02/11/2012 11:32, Roberta Presta ha scritto:
> Using a definition without <sequence>, on the other hand, means that 
> you can find only one <spatialInformation> describing a capture. The 
> capture.  That chance could be exploited in case of composed capture 
> to describe spatially each component  by adding  a 
> <spatialInformation> element for each of them (I don't know if it 
> could be really useful, I have left the definition "as is" to the aim 
> of discussing about it).
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]
           http://www.comics.unina.it/simonpietro.romano

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 Nov 2012 09:54:59 -0400

> <spatialInformation> describing a capture.

Oh, duh! Sorry. I totally missed the "unbounded". Now I understand the 
difference.

> have left the definition "as is" to the aim of discussing about it).

Thanks for pointing that out now. That deserves some discussion.

There is a slippery slope here into some major complexity. We started to 
talk about that at the interim. In the case of a switched capture where 
all of the switched sources come from the same scene this could be 
somewhat meaningful, though I wonder if it would be *useful*. In the 
case of a composed capture where all the sources come from the same 
scene I have difficulty understanding how to make any sense of this 
info. And this isn't even capable of representing the case of a switched 
or composed capture where the sources come from *different* scenes.

> What is the option that makes more sense to you?

Let's discuss a bit and see what others have to say. For now I think 
that the latter may be the most expedient choice.

	Thanks,
	Paul