Re: Problem with reg-event that needs immediate fix
Pete Cordell <pete <at> tech-know-ware.com>
2004-01-08 10:13:26 GMT
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
pete <at> tech-know-ware.com
http://www.tech-know-ware.com
+44 1473 635863
=============================================
----- Original Message -----
From: "Cullen Jennings" <fluffy <at> cisco.com>
To: "Jonathan Rosenberg" <jdrosen <at> dynamicsoft.com>; "sipping"
<sipping <at> ietf.org>
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" <jdrosen <at> dynamicsoft.com> 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:joe <at> bar.com" id="a7" state="active">
> > <contact id="76" state="active" event="registered"
> > duration-registered="0">sip:joe <at> pc34.bar.com</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:joe <at> bar.com" id="a7" state="active">
> > <contact id="76" state="active" event="registered"
> > duration-registered="0">
> > <uri>sip:joe <at> pc34.bar.com</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 sip-implementors <at> cs.columbia.edu for questions on current sip
> Use sip <at> ietf.org 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 sip-implementors <at> cs.columbia.edu for questions on current sip
Use sip <at> ietf.org for new developments of core SIP
RSS Feed