Subject: Re: [Sipping] Problem with reg-event that needs immediate fix

From: "Pete Cordell" <[email-masked]>
Date: Thu, 8 Jan 2004 10:13:26 -0000

Jonathan, Cullen,

One concern I have about many XML schemas defined in this space is how they
will be extended for subsequent versions.  Has a strategy been defined?

The reason I mention it is that I read an article on xml.com about
versioning (http://www.xml.com/pub/a/2003/12/03/versioning.html) and it
proposes adding additional syntax to a schema to allow an instance
conforming to a new version of a schema to be correctly validated against a
previous version of the schema.

It uses <xs:any namespace="##other"> (the form used in a lot of the SIP
schemas) to allow for 'third party' extensions.

But, to allow the schema to be extended with new elements it suggests the
following format (I've tried to mark the relevant bits with ****s):

<s:complexType name="CallbackType">
 <s:sequence>
 <s:element name="callbackLocation" type="s:anyURI"
minOccurs="1" maxOccurs="1"/>
**** <s:element name="Extension" type="wscb:ExtensionType"
            minOccurs="0" maxOccurs="1"/>*****
 <s:any processContents="lax" minOccurs="0"
maxOccurs="unbounded" namespace="##other"/>
 </s:sequence>
 <s:anyAttribute/>
</s:complexType>

*****
<s:complexType name="ExtensionType">
 <s:sequence>
 <s:any processContents="lax" minOccurs="1"
maxOccurs="unbounded" namespace="##targetnamespace"/>
 </s:sequence>
******

 <s:anyAttribute/>
</s:complexType>

If an extension is added to the schema, (I think!) it would become:

<s:complexType name="CallbackType">
 <s:sequence>
 <s:element name="callbackLocation" type="s:anyURI"
minOccurs="1" maxOccurs="1"/>
<s:element name="Extension" type=******"wscb:MyExtension"*****
            minOccurs="0" maxOccurs="1"/>
 <s:any processContents="lax" minOccurs="0"
maxOccurs="unbounded" namespace="##other"/>
 </s:sequence>
 <s:anyAttribute/>
</s:complexType>

*****
<s:complexType name="MyExtension">
 <s:sequence>
  <s:element name="myNewElement" type="xs:string"/>
<s:element name="Extension" type="wscb:ExtensionType"
            minOccurs="0" maxOccurs="1"/>
</s:sequence>
</s:complexType>
*******

<s:complexType name="ExtensionType">
 <s:sequence>
 <s:any processContents="lax" minOccurs="1"
maxOccurs="unbounded" namespace="##targetnamespace"/>
 </s:sequence>
 <s:anyAttribute/>
</s:complexType>

An alternative would be to define all new extensions in a separate
namespace.  However, this becomes a bit imprecise because its not easy to
say where the new material plugs into the original schema.

So my question is this an issue, or have I just not found the right
document?!

Happy New Year,

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
[email-masked]
http://www.tech-know-ware.com
+44 1473 635863
=============================================

----- Original Message -----
From: "Cullen Jennings" <[email-masked]>
To: "Jonathan Rosenberg" <[email-masked]>; "sipping"
<[email-masked]>
Sent: 30 December 2003 17:34
Subject: Re: [Sipping] Problem with reg-event that needs immediate fix

>
> I would prefer to change the Schema to be right for this things we know
are
> coming even if that broke backwards compatibility.
>
> The more I look at the schema, I think the whole the things could be
> structured a little better for extensibility. I had the same comment on
some
> of the other schema that have been in sipish drafts. We should probably
make
> this part of our NITS review.
>
> Cullen
>
> On 12/18/03 9:13 AM, "Jonathan Rosenberg" <[email-masked]> wrote:
>
> > While implementing the sipping reg-event draft, we ran into a serious
> > technical problem.
> >
> > The problem is that the specification has not left sufficient room for
> > extensibility within the XML schema. It allows for new information to
> > be added to the <registration> element (which describes the AOR), but
> > does not allow any additional information to be provided about a
> > contact. We ran into this problem because we needed to add path
> > information (ala rfc 3327) to the notifications, but this information
> > is per contact. There is no way to do this with the current
specification.
> >
> > The essence of the problem is that the contact element has, as
> > content, the actual URI. This makes it difficult to add other
> > information about the contact. A better approach would have been to
> > make the contact element a complex type, which would include an
> > element called <uri> that contains the uri.
> >
> > For example, today we have:
> >
> > <?xml version="1.0"?>
> >   <reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
> >                version="1" state="partial">
> >     <registration aor="sip:[email-masked]" id="a7" state="active">
> >       <contact id="76" state="active" event="registered"
> >                duration-registered="0">sip:[email-masked]</contact>
> >     </registration>
> >   </reginfo>
> >
> > whereas it ought to have been:
> >
> > <?xml version="1.0"?>
> >   <reginfo xmlns="urn:ietf:params:xml:ns:reginfo"
> >                version="1" state="partial">
> >     <registration aor="sip:[email-masked]" id="a7" state="active">
> >       <contact id="76" state="active" event="registered"
> >                duration-registered="0">
> >                   <uri>sip:[email-masked]</uri>
> >       </contact>
> >     </registration>
> >   </reginfo>
> >
> >
> > The schema for the contact element could then allow for other children
> > in other namespaces, giving us the needed extensibility.
> >
> > Unfortunately, there is other per-contact data we might want to add in
> > the not-too-distant future, such as callee-caps information. That kind
> > of data would be very useful for presence applications, where the
> > presence server could obtain it from the registrar using reg-event.
> >
> > I believe that this problem is significant enough that we should try
> > and address it during auth48. For those of you not familiar with it,
> > auth48 is a brief period just before publication of the actual RFC
> > where the author can correct typos or minor other problems. It is
> > possible, with AD approval, to make more substantive changes as I am
> > suggesting (and indeed I already ran this by Allison and she is OK).
> > Of course, I still need group consensus on any change. So, here is my
> > proposal.
> >
> > PROPOSAL
> >
> > My proposal for fixing this, as outlined above, is to modify the XML
> > schema. The <contact> element will instead become a complex type. It
> > will have, as children, a sequence of <uri> followed by an optional
> > element from any other namespace. The <uri> element will contain the
> > actual contact URI.
> >
> > Unfortunately, this proposed solution above is not backwards
> > compatible with the current draft.
> >
> > I considered other solutions as well:
> >
> >
> > ALTERNATE 1
> >
> > Modify the schema to allow attributes in the contact element from
> > other namespaces. Adds some extensibility, but is very bad for more
> > complex data, such as path or callee-cap data. Using attributes for
> > that data will require us to define a lot of structure within each
> > attribute. This approach is backwards compatible, but not forwards
> > compatible. That is, an implementation compliant to the schema before
> > this change would reject documents created by an implementation
> > compliant to the schema after the change.
> >
> > ALTERNATE 2
> >
> > Modify the schema to contain a new element, child to the
> > <registration> element. This element would be called "alt-contact",
> > and would be defined as I suggest above for contact. Whenever new
> > information is needed about a contact, the "alt-contact" element would
> > be present, and contain that extension data. The document would also
> > still contain a contact element, repeating the URI and other
> > attributes. This would provide forwards and backwards compatibility,
> > at the expense of a horrible hack that would repeat a lot of
> > information in the document.
> >
> >
> > I found neither of the two alternatives very palatable, which is why
> > my proposal is to fix this now, and do it properly, while we still can.
> >
> > Please provide input on the proposal ASAP. I'd like to come to
> > consensus in the next week or so (before everyone disappears for
> > vacations).
> >
> > Thanks,
> > Jonathan R.
>
>
> _______________________________________________
> Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 09 Jan 2004 01:47:43 -0500

inline.

> will be extended for subsequent versions.  Has a strategy been defined?

The general approach is to add <xs:any namespace="##other"> in places 
where we believe more data will be needed in the future. Nothing 
beyond that.

> previous version of the schema.

Right.

> maxOccurs="unbounded" namespace="##targetnamespace"/>

I'm not sure why this is a better idea. The general technique of just 
adding an <xs:any> tag directly gets you the same result. The above 
approach merely wraps the extension element in another element called 
<Extension>. I dont see why thats useful.

> maxOccurs="unbounded" namespace="##targetnamespace"/>

I dont see why you simply cant define the new schema with the new 
element anywhere you previously, in the old schema, allowed elements 
from any namespace.

> namespace.

Each extension normally has its own namespace.

>  However, this becomes a bit imprecise because its not easy to

I don't think we've planned specifically on how one might specify 
where to plug the new material into the existing schema. RPID, for 
example, which is an extension to PIDF, merely defines the new 
elements. Validation that they are placed in the right places is not 
done via the resulting schema validation, but through normative text 
in the doc. That may be OK.

If you want to validate, via schema, that the elements are placed in 
the right place, you would define a new schema with the new element as 
optional, as above. Again, I dont see the need for wrapping it in a 
new element called <extension>.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: "Pete Cordell" <[email-masked]>
Date: Fri, 9 Jan 2004 11:01:11 -0000

As you know, the main issue of versioning is allowing devices working to the
old version of a schema to operate successfully when they receive instances
conforming to a new version of a schema.  (I'm assuming that we are not
expecting UAs to try and locate the latest version when a received schema
fails to validate.)

Unfortunately the use of <s:any namespace="##other"/> doesn't get you the
same result as the article proposes.

If the old version of the schema contains this fragment:

<s:element name="callbackLocation" type="s:anyURI"/>
  <s:any processContents="lax" minOccurs="0"
 maxOccurs="unbounded" namespace="##other"/>

An instance of a document conforming to a new version of the schema that
contains the following fragment would clearly not be valid against the old
schema if it contained the new element "newItem":

<s:element name="callbackLocation" type="s:anyURI"/>
<s:element name="newItem" type="newitem" minOccurs="0"/>
  <s:any processContents="lax" minOccurs="0"
 maxOccurs="unbounded" namespace="##other"/>

At first sight, using the ##any option to xs:any might seem the way to go,
e.g.:

<s:element name="callbackLocation" type="s:anyURI"/>
  <s:any processContents="lax" minOccurs="0"
 maxOccurs="unbounded" namespace="##any"/>

However, this violates the Unique Particle Attribution Constraint, the
relevant bits being:

- Two non-group particles overlap if ... One is a wildcard and the other an
element declaration, and the {target namespace} of the element declaration,
or of any member of its ·substitution group·, is ·valid· with respect to the
{namespace constraint} of the wildcard.

- A content model will violate the unique attribution constraint if it
contains two particles which ·overlap· and may ·validate· adjacent
information items and ...  the first has {min occurs} less than {max
occurs}.

The syntax in the original post was a way to get around this, allowing both
external additions, and new syntax in the existing schema without violating
this Unique Particle Attribution constraint.  (e.g. any variable cardinality
element would conflict with the <xs:any ##any> particle, but this wouldn't
be the case if an optional element named "Extension" wrapped local
extensions.)

One option might appear to be to define the new element in a completely new
schema, in a completely new namespace.  The fragment in the existing schema
would then be modified to include a new reference to the element of the
form:

 <s:element name="callbackLocation" type="s:anyURI"/>
<s:element xmlns:v2="urn:...:v2" ref="v2:newItem" minOccurs="0"/>
  <s:any processContents="lax" minOccurs="0"
 maxOccurs="unbounded" namespace="##other"/>

Unfortunately this seems to violate the Unique Particle Attribution
Constraint also; same reason, different namespace.

So without doing anything we are left with defining version 2 extensions in
separate schemas with different namespaces, and specifying where they should
be plugged in using narrative (or possibly some form of XPath in
non-standard xs:appinfo sections).  This manual process seems a major source
of potential errors and defeats some of the benefit of using schemas in the
first place.

Adding in the extra syntax seems the correct way to go.  Much of the burden
of adding the syntax could potentially be saved by defining suitable groups
(one for sequences, one for choices).

Pete.
http://www.xml2cpp.com