DR702 Requirement for Evolution

From the text:
>DR702 Requirement for Evolution 
>The XP specification must define the concept of protocol 
>evolution and define a mechanism or mechanisms for 
>identifying XP revisions. This mechanism or mechanisms 
>must ensure that given two XP messages it should be possible, 
>by simple inspection of the messages, to determine if 
>they are compatible. The specification must define the 
>concepts of backwards compatible and backwards incompatible 
>evolution. Furthermore, the XP envelope must support both 
>optional and mandatory extensibility of applications using 
>the XP envelope. 

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):
  The XP specification must define the concept of protocol 
  evolution and define a mechanism or mechanisms for 
  identifying XP revisions. Because XP envelopes are to be 
  defined by XML Schemas [DR701], evolution of the envelope 
  will be defined in terms of the schemas which in turn 
  define them.  It should be simple for an application to 
  determine the version of a message by checking the
  schema which governs the envelope.  Since the contents
  of the envelope will also likely be constrained by an 
  XML Schema, the application can check the version of
  the message by the same means.  (A simple way to implement
  an easy check might be through control of the URIs used
  to identify the schemas involved).  The specification will
  define forward compatibility and backward compatibility
  with regard to envelopes and contents, attempting to 
  leverage the parallel concepts currently being developed
  in other working groups. 

Now I'm going a bit far, but I'd like to explain.  The purpose
of the requirements is to help set our direction, and here's
where I hope we are going... 

Because DR701 says that an envelope will be defined by
an XML Schema (I think that's a good thing), the relationships
between any two envelope instances can be understood in
terms of relationships between the schema information sets 
involved.  The Schema WG has recognized for a long time that
types (either complex or simple) can be either extended or 
restricted, but that these processes, while necessary to 
support evolution, are not sufficient.

In this context, "evolvability" is a relationship between
the types involved in the exchange.  Those types are
defined in the schemas.  (That simple inspection will not
tell us whether the types are truly "evolutionarily safe".)

In my current thinking, evolution means the following 
(instance documents are messages):

Given an instance document D described by a schema S, and
a newer instance document D' described by a newer schema S',
a processor will have either an application A (which 
understands schema S) or a newer application A' (which
understands schema S').  

1) A can use S to parse D (trivial)
2) A' can use S' to parse D' (trivial)
3) A can fetch S' to parse D' and safely handle the post
   schema-validation infoset.
4) A' can use S' to parse D.  The application (A') must
   have been coded to know what to do if S stuff shows
   up.

One final point:  "mandatory" and "optional" are defined
in terms of the documents, i.e. the schemas involved.
We should try to avoid introducing features into XP which
are already defined elsewhere...

Thanks,
David

Received on Saturday, 11 November 2000 21:22:46 UTC