Re: DR702 Requirement for Evolution

Just a quick question -- is the document being discussed only available for
view by the committee, or is there a URL?

-- Kurt Cagle
----- Original Message -----
From: "David Ezell" <David_E3@Verifone.Com>
To: <xml-dist-app@w3.org>
Sent: Saturday, November 11, 2000 7:22 PM
Subject: 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:42:32 UTC