RE: [DR305] Complex apps

David/Martin,

Are you saying that these items should be addressed in future revisions of
the XP spec or are you suggesting that other external standards bodies or
initiatives might also tackle these issues?

I share the desire to keep scope manageable, and would like to see this DR
acknowledge that specific problems such as sessions and transactions may be
addressed by other activities and not necessarily XP.

How about modifying:

	"...(in future specifications)"

to something like

"...(in external specifications or future revisions of the XML Protocol
specification)..."

This acknowledges that work may happen elsewhere but still leaves room for
future XP activities much like XHTML and the modularization activity (maybe
not the best example but should convey the idea).  

-Randy




-----Original Message-----
From: David Ezell [mailto:David_E3@Verifone.Com]
Sent: Thursday, November 16, 2000 10:07 AM
To: 'xml-dist-app@w3.org'
Cc: 'Williams, Stuart'
Subject: [DR305] Complex apps


On Wed 11/15/2000 6:37 PM+5:00 Martin Gudgin wrote:
>We're in grave danger of biting off more than we can chew. I do not want to
>commit at this stage to all the things listed here ( authentication,
>encryption, reliable delivery, sessions and transactions ). I think XP
>should not PRECLUDE these things, but I think they should be provided in
>seperate specs.

Agreed.  The intent is to express only a little more than "not preclude",
in that it should "encourage a common approach" for providing such
facilities, which would make the follow-on specs you mention easier
to create.  We do not mean to imply that XP would contain a design for
these facilities.

Possibly as follows.  It better expresses the intent in the first
sentence.  


DR305 (Absorbs old DRs: DR003) 
The XML Protocol design SHOULD encourage a common approach for
providing facilities (in future specifications) which can support
complex applications.  Such applications may be characterized
as having higher consequences of failure, leading to the following
needs:  the need to ensure message integrity (authentication) and 
privacy (encryption), the need to be aware of delivery semantics
(reliable delivery, path to service), and the need to support more 
complex exchange patterns for long-lived sessions and for 
transactional semantics (sessions and transactions). 

Thanks
-David

Received on Thursday, 16 November 2000 13:08:31 UTC