RE: [XCON] Discussion Point 4: XML Schema Structure

["Chris Boulton" <cboulton at ubiquity.net>]

I personally think #2 is the most appropriate.  The core focus must be
that endpoints can at the very least render the common conference
information (I'm not against using #3 if the WG convinces me).

Chris.


-----Original Message-----
From: Adam Roach [mailto:adam at nostrum.com] 
Sent: 08 February 2005 20:42
To: XCON-IETF
Subject: [XCON] Discussion Point 4: XML Schema Structure

[as chair]

The XML schema used to describe a conference object contains common 
conference information (the portion that doesn't vary depending on the 
type of conference) in addition to a conference template section. There 
are three ways this can be represented:

   1. The top-level information is the template section, and it contains
      a subsection that is the common conference information. This has
      the advantage that the schema can all be well defined: because the
      common conference information is known at the time the template is
      developed, the appropriate schema definition can be inserted into
      the template schema. The downside is that this setup requires
      navagation of the template information to get to the common
      information, which is likely to be manipulated more frequently.
   2. The top-level information is the common conference information,
      which contains the template information. This has the advantage
      that clients don't even need to care about the template being used
      to allow rendering and control over basic conference functionality
      (which will suffice for many clients, especially those with
      limited screen real estate). The downside is that the common
      conference information schema must include an arbitrary exension
      point to allow new templates to hook into the schema. This make
      schema validation very difficult.
   3. The template information and common conference information are
      conveyed as two separate objects (e.g. using multipart mime). This
      provides the benefits of allowing completely separate schema,
      straightforward schema validation, and easy access to the common
      conference information. The downside is that any mechanism for
      separating the schema is going to add some amount of protocol
      complexity (although it can be argued that it is increasingly
      difficult to find a potential client of the XCON protocols that
      doesn't already support multipart mime).

Which approach should we take?

/a

_______________________________________________
XCON mailing list
XCON at ietf.org
https://www1.ietf.org/mailman/listinfo/xcon


This email and any attached files are confidential and copyright protected.  If you are not the addressee, any dissemination, distribution or copying of this communication is strictly prohibited.  Unless otherwise expressly agreed in writing, nothing stated in this communication shall be legally binding.

_______________________________________________
XCON mailing list
XCON at ietf.org
https://www1.ietf.org/mailman/listinfo/xcon