RE: additional para from 31 oct telecon

I think that this reworking of the last sentence is much clearer.  It
completely dispells my confusion.
 
-----Original Message-----
From: Doug Bunting [mailto:db134722@iplanet.com] 
Sent: Tuesday, November 05, 2002 4:48 PM
To: Cutler, Roger (RogerCutler)
Cc: 'Jeff Mischkinsky'; www-ws-arch@w3.org
Subject: Re: additional para from 31 oct telecon


Roger,

Starting with your second point (the business context): In the EDI
world, Implementation Guides are often far larger than the underlying
standards specifications.  It can take many consultants, developers and
business analysts working for many months to get from legal contract to
first production business document exchange.  One year later, the
agreement changes slightly and both sides need to find those consultants
again.  This illustrates two related problems: The need to describe this
information for human use and the common inflexibility (hard coding) of
the implementations.

Since one part of the deployment process that's presently manual is
implementing and enforcing the appropriate sequencing (choreography) of
interactions between the trading partners, automation of this deployment
step should be a big win to Chevron Texaco.  In short, we're trying to
save you some time and money.  It doesn't solve the entire manual
deployment problem but does continue the chipping away at it begun with
interoperable messaging solutions (no need to recode at that layer) and
interface description languages (easier to respond to changes and
variance between your relationships).  We aren't replicating an existing
EDI feature, we're working on one of its oft mentioned issues (time to
deployment).  A general solution may even be applicable for future EDI
deployments.

On the last sentence (the standards context): The point was around the
ability for vertical standards bodies to use a standard language when
describing the relationship between the documents they define.  This
horizontal standard would support the vertical standard development
effort, providing those bodies (OTA, RossettaNet, CIDX, AIAG, STAR, ...)
with standard infrastructure and allowing them to concentrate on adding
value in their problem domain.  It also allows vendors to create
horizontal solutions more adaptable to the demands of the different
verticals.  Again, this saves money for customers such as Chevron Texaco
because the software you purchase is configured for your requirements
and not developed against them (scaling the market).

I'm now wondering whether "vertical" is required in the above
description and whether the interoperable implementation value is a
footnote on the ability to focus.  Could we rephrase Jeff's last
sentence as:

	As well, creating a standard language to describe the
relationships between document exchanges will be helpful to other
standards bodies, such as RosettaNet or CIDX, giving them a standard
infrastructure for message choreography and enabling them to focus on
the core competencies relevant to their domain.
	

thanx,
    doug
Cutler, Roger (RogerCutler) wrote:


	Looks pretty good to me.  However, I honestly do not understand
the last
	sentence at all.  I'm not disagreeing with it, I'm just not
getting it.  Is
	there some way that you can recast or expand it to make it more
clear?
	
	Maybe I should try to be more explicit about my confusion, if
that is
	possible.  In this sentence I don't understand what "standards
context"
	means.  Using or makinfg standards?  Does "specification of
choreographies"
	mean specifying techniques of expressing choreographies or
specific
	instances of choreographies (like "A sends an invoice to B")?
In either
	case, what does it mean to be interoperable and what is the
value?  Is this
	interoperable between Oracle and IBM or between W3C and OASIS?
I think,
	from the discussion on the phone, that it may be the latter.  If
so, I
	really think that this needs to be explained more clearly and
the actual
	area of value added explicitly pointed out.
	
	So far, "reduce the cost of integrating with new trading
partners and
	responding to changes in existing interfaces [that effect the
logic of the
	message exchanges]" is the core of the business value I am
seeing displayed.
	Are there any other payouts?  It really seems to me that there
might be, but
	I'm not coming up with anything real specific.
	
	As it stands, it seems to me that this business value may be
achieved by a
	rather small subset of the complex specs in play.  That is, what
I would
	call (probably not very accurately) the message sequencing part.
	
	-----Original Message-----
	From: Jeff Mischkinsky [mailto:jeff.mischkinsky@oracle.com] 
	Sent: Friday, November 01, 2002 3:59 AM
	To: www-ws-arch@w3.org
	Subject: additional para from 31 oct telecon
	
	
	
	Hi,
	    Here's my attempt to capture today's discussion centering
around adding 
	a description of the business drivers for developing a
choreography spec.
	
	This goes right before Section 1.1 - Inputs
	
	cheers,
	   jeff
	
	  WSDL has proved very useful for describing a single service.
Currently 
	complex natural language describing the obligations of the
participants 
	detailing how to use a service (sequencing, state management,
etc.) have to 
	accompany a WSDL description. The next step is to partially
replace these 
	somewhat imprecise instructions with precise language. This will
simplify 
	the daunting task companies now face when trying to use web
services to 
	integrate their business processes. In a B2B context such a
specification 
	could reduce the cost of integrating with new trading partners
and 
	responding to changes in existing interfaces. In a standards
context it 
	will allow the development of specifications of choreographies
in 
	sufficient detail to enable interoperable implementations.