RE: DR702 Requirement for Evolution

> As written, the above implies that we are concerned with
> the evolution of XP only.  I think we should go a little
> farther.
> I propose (adding some stuff in the middle and leaving out
> the end):

While I agree that evolvability is at least as important as evolvability of
the envelope, the last paragraph is really what defines the evolvability model
for application and would be unfortunate to omit.

The extensibility model described in the last paragraph is not in fact covered
by schema - the intent is that there will be a schema for the envelope which
allows the applications to add features that they define independently - for
example in terms of schemas. That is, an XP message is an envelope defined by
a schema where the envelope can contain a set of independently defined
"modules" each with their own schema. In other words, there will rarely (if
ever) be a schema for the complete message.

This is illustrated in what I call the "vertical composability model" which
you can find described in [1] - a presentation that I gave on SOAP recently.
The need for a "mandatory" flag is also described by TimBL in [2].

It is very important that there is an explicit mechanism for indicating which
features in an envelope are optional and which are mandatory. We can not
expect people to look for a schema for the XP envelope every time they use XP
and so anything that is mandatory must be explicitly in the message from day
one.

One interesting thing note about the current wording of 702 is that it nowhere
says that the evolvability model for XP itself can't be the same as for
applications using XP. That is, a perfectly valid solution would be to say
that XP envelope evolution can be negotiated using an XP header.

Henrik

[1] http://jeffsutherland.org/oopsla2000/xpo/nielsen/nielsen_files/frame.htm
[2] http://www.w3.org/DesignIssues/Mandatory.html

Received on Sunday, 12 November 2000 14:41:29 UTC