Subject: [XCON] Cloning: Additional data in the data model

From: "Oscar Novo" <[email-masked]>
Date: Thu, 15 Jan 2009 12:24:15 +0100

Hi folks,

In IETF-73 has been a proposal to expand the data model to support the
cloning method defined in the framework. At the moment, the data model
supports the cloning method though the 'cascaded-focus' element which
contains a 'parent' conference URI but it might be needed to add few
more elements to be align with CCMP. 

Some elements that could be added are:

- An element that contains all the 'non-independent' children
conferences
- A policy attribute/element that indicates the "parent enforceable" of
every element. However, it would make more sense to add it in a draft
that discusses conference policies.

It would be nice to know the opinion of the WG whether we want to
support entirely this property or not. 

Cheers,

Oscar

_______________________________________________
XCON mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/xcon

---

From: [email-masked]
Date: Fri, 30 Jan 2009 19:16:05 +0100

Hi Oscar,

sorry for the late reply. IMHO, we might need in the data model:

1. information about the father/son relationship. This might be an  
attribute, e.g.:

<xs:attribute name="fatherEntity" type="xs:anyURI" use="optional"/>

2. information about the conference/sidebar relationship, e.g.:

<xs:attribute name="sidebarOf" type="xs:anyURI" use="optional"/>.

As to the "parent enforceable" relationship, I would leave it outside  
of the data model.

Cheers,

Simon

-- 
                             _\\|//_
                             ( 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]

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

---

From: [email-masked]
Date: Fri, 30 Jan 2009 19:36:48 +0100

Hello again, Oscar. While working on the data model, we realized that  
the new schema you put in the draft (in appendix) does not define the  
XCON data model explicitely as an extension of the one contained in  
rfc4575. You import the mentioned schema, and you define further  
elements, which are the new ones introduced within XCON. This works  
fine, thanks to the presence of the "any" element:

<xs:any namespace="##other" processContents="lax" minOccurs="0"  
maxOccurs="unbounded"/>

Personally, I would have liked something more explicit, e.g.:

*****************************************************************

xmlns:info="urn:ietf:params:xml:ns:conference-info"

<xs:import namespace="urn:ietf:params:xml:ns:conference-info"   
	schemaLocation="rfc4575DataModel.xsd"/>

<xs:element name="conference-info" type="conference-type"/>

<xs:complexType name="conference-type">
  <xs:complexContent>
   <xs:extension base="info:conference-type">
    <xs:sequence>
     <xs:element name="conference-password" type="xs:string"/>
     <xs:element name="mixing-mode" type="mixing-mode-type"/>
     <xs:element name="codecs" type="codecs-type"/>
     <xs:element name="controls" type="controls-type"/>
     <xs:element name="language" type="xs:language"/>
     <xs:element name="allow-sidebars" type="xs:boolean"/>
     <xs:element name="conference-time" type="conference-time-type"/>
     <xs:element name="allow-conference-event-subscription" type="xs:boolean"/>
     <xs:element name="to-mixer" type="mixer-type"/>
     <xs:element name="provide-anonymity" type="provide-anonymity-type"/>
     <xs:element name="allow-refer-users-dynamically" type="xs:boolean"/>
     <xs:element name="allow-invite-users-dynamically" type="xs:boolean"/>
     <xs:element name="allow-remove-users-dynamically" type="xs:boolean"/>
     <xs:element name="from-mixer" type="mixer-type"/>
     <xs:element name="join-handling" type="join-handling-type"/>
     <xs:element name="user-admission-policy"  
type="user-admission-policy-type"/>
     <xs:element name="allowed-users-list" type="allowed-users-list-type"/>
     <xs:element name="deny-users-list" type="deny-users-list-type"/>
     <xs:element name="floor-information" type="floor-information-type"/>
    </xs:sequence>
   </xs:extension>
  </xs:complexContent>
</xs:complexType>

*******************************************************************************

This solution looks a bit "cleaner" to me, even though it might  
violate the Unique Particle Attribution constraint with some XML  
engines (e.g. JAXB).

What is your feeling about this?

Simon

---

From: Mary Barnes <[email-masked]>
Date: Sat, 31 Jan 2009 05:27:29 -0600

Oscar and Simon,
1.  Shouldn't we call it "parent/child" or "mother/daughter" relationship ;)
 Obviously, the latter is the pc choice.

I'm also still thinking we need the "independent" info. While the logic
would be handled by the conference server - e.g., can the parent be deleted?
 I think the client needs to know this, so that they don't try to delete a
parent and they are aware that when they get any updates, why that's
happening. I also think it might be useful for debug and administration.

Thanks,
Mary
--who also apologizes for the late reply
-- and I'm traveling (with my new mac :)  and corporate email access (via
secure web i/f) is so, so, so, slow.

On Fri, Jan 30, 2009 at 12:16 PM, <[email-masked]> wrote:

> As to the "parent enforceable" relationship, I would leave it outside of
> the data model.
>
> Cheers,
>
> Simon
>
>