Subject: [Simple] Question about extending mood in rpids-04

From: Cullen Jennings <[email-masked]>
Date: Sat, 06 Nov 2004 16:07:54 -0800

Say we later wanted to add the ability in the mood to say that one was
feeling very fluffy today, how would we do that in a backwards compatible
way? Do we need some other element or something that contains a text
descriptions and perhaps icon? The way we did this looks very much like a
have to get it right the first time approach.

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 06 Nov 2004 20:29:33 -0500

The current approach would require an extension of the schema. A 
slightly less heavy-weight approach would be a variation of the 
XMPP/Jabber approach, as in

<mood>
   <other note="fluffy" />
</mood>

The same issue exists for all the enumerations and should probably be 
handled in a similar fashion.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 07 Nov 2004 08:23:19 -0500

I think it's fairly important to get this right, and deserves some 
broader attention.

Firstly, I think that whatever mechanism we do should definitely be 
applied the same across rpid elements. Right now, the schema uses 
several different techniques.

Secondly, I think you can enumerate the approaches:

1. Generic element names

In this approach, the value of the element contains the information of 
interest. Something like this:

<activity>working</activity>

Extensibility is easy; the schema allows <activity> to contain a string, 
and you manage this through IANA.

2. Specific element names

In this approach, the element name contains the information of interest:

<working/>

There are two variations on this:

a. the schema uses substitution groups, declaring an abstract element 
like <activity> that things like <working> replace

b. the schema allow elements from any namespace

3. Attribute values

Attributes contain the information of interest:

<activity iam="working"/>

So, which to do?

I strongly believe we should use 2a. The reasons are:

I: It allows XML namespaces to easily be applied to differentiate values 
created by one group from those created by another, without requiring 
central organization through IANA for everything.

II: Subtitution groups allow additional schema validation, so that 
things that are really an activity appear within an activity element

III: It allows for values that are more structured than just a token, 
should the need arise

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 07 Nov 2004 14:12:01 -0500

I think we're in general agreement. The only sub-case that is not 
addressed is where the value is to be added by the user, not a schema. 
My attribute proposal discussion was only to address that particular case.

It is a separate question whether we only allow IANA-sanctioned moods or 
whether users are allowed to create their own mood (using legal 
substances, naturally).

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sun, 07 Nov 2004 16:58:04 -0500

> My attribute proposal discussion was only to address that particular case.

These things will always be in the category of "notes" since they can 
only be understood by humans. I think you address that by just defining 
an element called note which allows that:

<mood>
   <happy/>
   <excited/>
   <note>big grin</note>
</mood>

Since each mood element (i.e., each member of the substitution group) 
can have as complex a structure as needed, in this case, we are saying 
that one value, <note> has a structure which includes a textual string 
for purposes of rendering to the human user.

> whether users are allowed to create their own mood (using legal 

Mostly separate; using an element approach allows you to define an 
extensibility model where some values can be registered by IANA, and 
others just created and used, without fear of collision.

If we do want IANA registries, we need to be sure we understand what it 
takes to create the registry (standards action, open registration, etc.).

-Jonathan R.

---

From: Aki Niemi <[email-masked]>
Date: Mon, 08 Nov 2004 11:56:53 -0500

Hi,

Comment at the bottom.

> III: It allows for values that are more structured than just a token, 

I'm wondering about the future proofness when using the substitution 
groups. If the recipient is doing document validation, but doesn't 
possess the extension schema, will it be able to validate the document.

That seems like a bad thing, especially considering a composer might 
need to do document validation. It should be able to transparently treat 
data it doesn't understand, so that extensions can be made in endpoints 
only without requiring a network entity to be upgraded.

Therefore, 2b would seem like a better alternative here...

Cheers,
Aki