W3C home > Mailing lists > Public > xml-dist-app@w3.org > January 2001

DR305 -- proposed disposition

From: David Ezell <David_E3@Verifone.Com>
Date: Mon, 8 Jan 2001 17:31:13 -0500
Message-ID: <472E220BA79DD11186340060B06B38D9033AD1C5@tpantmail1.ssr.hp.com>
To: "'xml-dist-app@w3.org'" <xml-dist-app@w3.org>
On 2000-01-03, the working group requested that I post
a disposition of DR305 taking the essentials in that
proposed requirement and working them into the introductory
section of "4.2 Simplicity and Stability". 

I apologize for the length of this note, but the only
effective way to present the material is to show the
section in its (proposed) entirety.

The sections below are:
==1== Current introduction to "4.2 Simplicity and Stability"
==2== Current proposed revision of R305
==3== Proposed revised introduction to section 4.2
==4== Rationale 

[[]] around comments

==1== Current introduction to "4.2 Simplicity and Stability"
[[ note the introduction contains two requirements, R307
and R308 ]]

>Over the years, many different companies and individuals 
>have proven the ability to design and implement workable 
>open protocols for distributed computing that operate 
>largely within organisational boundaries. The design 
>centre for XP must include the interoperation of systems 
>across organisational boundaries. The aim is to exploit 
>Web philosophy and Web design principles in order to 
>help foster widespread decentralized computing on the Web.
>
>R307 
>XP must be suitable for widespread use across 
>organizational boundaries in support of the application 
>use cases supplied elsewhere in this document. This 
>suitability requirement implies simplicity in the language 
>of the XP specification, which itself describes a technology 
>that is simple to understand and to implement correctly 
>(see also R301, R301a). Although simplicity can only be 
>measured in relative terms, the Working Group should ensure 
>that the complexity of any solution produced is comparable 
>to that of other current and widespread Web solutions.
> 
>R308 
>Since XP is intended to be a foundation protocol, its 
>definition should remain simple and stable over time. 
>Explicit use of modularity and layering in the resulting 
>design will help assure longevity. Such a framework will 
>allow subsequent extension of the design while leaving 
>the foundation of the design intact. (R300, R302 and DR305 
>relate to stability).
>
>[[section not in a requirement]] 
>Requirements for simplicity and stability arise in the 
>context of the specification documents and in the context 
>of the protocol technologies being defined.

==2== Current proposed revision of R305

>R305 
>
>In order to encourage a consistent approach for developing 
>features which are out of scope for the XP specification 
>itself, the XML Protocol Specification must provide 
>facilities and enumerate favored ways of applying those 
>facilities in support of such features.
>
>Examples of features which are out of scope but for which 
>consistent design will undoubtedly be beneficial are 
>1) message authentication and encryption (perhaps using 
>SMIME, SSL, or digital signatures), 2) sessions and 
>transactions (possibly by providing globally unique 
>identifiers for messages), and 3) service definition and 
>discovery.
>
>SOAP 1.1 facilities such as the "Header" element and the 
>"encodingStyle", "mustUnderstand", and "actor" attributes 
>are examples of the kinds of support facilities and use 
>patterns addressed in this requirement.

==3== Proposed revised introduction to section 4.2

>Over the years, many different companies and individuals 
>have proven the ability to design and implement workable 
>open protocols for distributed computing that operate 
>largely within organizational boundaries. The design 
>center for XP must include the interoperation of systems 
>across organizational boundaries. The aim is to exploit 
>Web philosophy and Web design principles in order to 
>help foster widespread decentralized computing on the Web.
>
>R307 
>XP must be suitable for widespread use across 
>organizational boundaries in support of the application 
>use cases supplied elsewhere in this document. This 
>suitability requirement implies simplicity in the language 
>of the XP specification, which itself describes a technology 
>that is simple to understand and to implement correctly 
>(see also R301, R301a). Although simplicity can only be 
>measured in relative terms, the Working Group should ensure 
>that the complexity of any solution produced is comparable 
>to that of other current and widespread Web solutions.
> 
>R308 
>Since XP is intended to be a foundation protocol, its 
>definition should remain simple and stable over time. 
>Explicit use of modularity and layering in the resulting 
>design will help assure longevity. Such a framework will 
>allow subsequent extension of the design while leaving 
>the foundation of the design intact. (R300 and R302 
>relate to stability).
>
>[[section not in a requirement]] 
>
>[[ added text ]]
>Simplicity in XP implies that many potentially important
>features are out of scope for XP proper.  However, the XP 
>working group recognizes that providing consistent ways to
>support these out of scope features will help keep XP
>stable.  Examples of such features are 1) message 
>authentication and encryption (perhaps using SMIME, SSL, 
>or digital signatures), 2) sessions and transactions 
>(possibly by providing globally unique identifiers for 
>messages), and 3) service definition and discovery. 
>Facilities to support features like these may resemble
>SOAP1.1 facilities such as the "Header" element.
>[[ end added text ]]
>
>Requirements for simplicity and stability arise in the 
>context of the specification documents and in the context 
>of the protocol technologies being defined.

==4== Rationale 

Some minor edits were made to make the text compliant with
US English.

In general, I tried not to upset the already approved wording
of the preamble section.  None of the existing text was
modified, except removing a reference to DR305.  I only added 
a section after R308 and before the final sentence.

I judged the most important residual information to be the 
types of requirements deemed "out of scope but needing 
support of some sort".

In the added section, I avoided "requirement words" like 
"should" or "must".

I left in the reference to SOAP 1.1, though it is much
reduced.  I feel it's presence lends at least a little
concrete evidence pointing to what we're talking about here.

Priority feedback request:  I'm not sure that "the XP working
group" is the right subject for the second sentence.

All the best,
David Ezell  
Received on Monday, 8 January 2001 17:31:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:58 GMT