RE: data parameter elements

Hi Greg and James,

A little levity if you don't mind.  The first letter of SWAP stands for
Simple.  And while there are certainly many more elegant ways to accomplish
almost any aspect of SWAP, if we include several optional ways (however more
elegant) that makes it more complex, that makes it harder to program because
you have to test to see which option was used, etc.  I hope we don't change
Simple to Complex because we would then end up with CWAP.

Michael Oliver
Senior Technical Research Engineer
Product Marketing
Open Text Corporation
7391 S. BullRider Ave.
Tucson, AZ 85747
(520)574-8272 Voice
(520)574-8273 Fax
ollie@opentext.com
http://www.opentext.com

-----Original Message-----
From:	ietf-swap-request@w3.org [mailto:ietf-swap-request@w3.org] On Behalf
Of Gregory Alan Bolcer
Sent:	Wednesday, October 14, 1998 9:14 AM
To:	James.Anderson@mecomnet.de
Cc:	ietf-swap@w3.org
Subject:	Re: data parameter elements

Hi James,
  My feeling is that, yes, this is a way to accomplish this,
but I would classify your suggestion in the category of "Wwhy don't
we just use {IPP, XML/RPC, HTTP, WebDAV...}?  There's a tradeoff
at work here.  SWAP needs to define a common set of goals that
almost all workflow tool vendors need from theirs and other
systems.   Communicating across the network you have any
number of transport mechanisms.  the Goal of SWAP is to provide
richer transport and simpler notification than existing
network interfaces that can be standardized.   One one end of
the spectrum, you can simply use HTTP(/1.1) and embed all
or your smarts into an XML form.  This is similar to the WfMC's
Mime bindings.  While the transport is simple, the overhead
of computing smarts on the receiving end to accomplish a task
requires a) a lot of agreements and understanding between the
two sites, and b) a fairly complex component to interpret
the swap and data calls.  On the other end of the spectrum
is the full WfMC interface specs (or the OMG's Joint Flow).
It's a very rich, powerful, and robust set of interfaces,
but requires even more of a computing overhead on the
receiving and sending end.  The SWAP effort appears to be taking
a little different approach.  WebDAV has shown the benefits
to having a little more powerful set of transport primitives.
SWAP wants to incrementally add just a few more to better
support cooperation and control.  By having a little more
robuts transport mechanism, you can have a much simpler
method for cross-platform workflow control, invocation, management,
monitoring, etc.  The benefit being that the required infrastructure
on the sending and receiving side can be simplified when
comparing the requirements of supporting other workflow
interfaces and standards across the network.


Take your example and write out the complete call.
I am assuming your are invoking a remote workflow service.
Write out, what does the  URI look like, how are the parameters
and data encoded, is the message synchronous or asynchronous,
what are the side-effects and results, what are the message
and error codes, what are the return values, how do you
use these values to accomplish the other goals?  The
devil's always in the details.

Anywys, these are just my opinions and understanding.

Greg


 > hello,
 >
 > i'm looking at the 9807 version of SWAP and ask why the data element in
 > messages is encoded as a list of name value pairs. why not just specify
 >
 > <!ELEMENT swap (interfaces, ..., data?) >
 > <!ELEMENT data ANY >
 >
 > and leave it to the respective processes to decide whether a list of
pairs
 > suits them or whether a more structured encoding is better?
 >

Received on Wednesday, 14 October 1998 17:39:52 UTC