Archived WfMC list serv messages from ALL Workgroups
MARCH – JUNE 2000.

Starts with most recent posts. This is a long document, please be patient.


Use your browser’s search/find capability to locate specific words or phrases. Any questions regarding the comments or content should be referred to the appropriate authors of same.

Any other questions can be referred to the WfMC Secretariat at wfmc@wfmc.org.

 

Workflow Management Coalition (Wf MC)

2436 North Federal Highway #374, Lighthouse Point, FL 33064, USA

Phone +1 954 782 3376, Fax +1 954 782 6365

email: layna@wfmc.org             http://www.wfmc.org/

 

 

There are 2 messages totalling 60 lines in this issue.

Topics of the day:

1. comments on “Workflow Standard” document (2)

 

----------------------------------------------------------------------

 

Date:          Tue, 27 Jun 2000 09:25:39 -0400

From:         Gignac Donald A CRBE <GignacDA@NSWCCD.NAVY.MIL>

Subject:      comments on “Workflow Standard” document

 

Here are some comments on the XML examples in the “Workflow Management Coalition Workflow Standard - Interoperability Wf-XML Binding” document.

Donald A. Gignac  gignacda@nswccd.navy.mil  301-227-3348

1.   Example 6

1.1  For greater clarity insert “<CreateProcessInstance.Request>” before “<ContextData>” and  “</CreateProcessInstance.Request>” after “</ContextData>” after removing the “ . . . “.

 

2.   Example 7

2.1  For greater clarity insert “<CreateProcessInstance.Request>” before “<ContextData>” and  “</CreateProcessInstance.Request>” after “</ContextData>” after removing the “ . . . “.

 

3.   Example 8

3.1  For greater clarity insert “<CreateProcessInstance.Request>” before “<ContextData>” and  “</CreateProcessInstance.Request>” after “</ContextData>” after removing the “ . . . “.

 

4.   Example 9

4.1  Since the first element type in the “WfMessage” content model is “WfTransport” (and not  “WfMessageTransport”), change “<WfMessageTransport/>” to “<WfTransport/>”.

4.2  For greater clarity insert “<CreateProcessInstance.Request>” before “<ContextData>” and  “</CreateProcessInstance.Request>” after “</ContextData>” after removing the “. . . “.

 

5.   Example 16

5.1  Since the “State” content model provided by “%vstates;” allows only element content and no  character data content, “<State>open.notrunning.suspeded</State>” must be changed to “<State><open.notrunning.suspeded></State>”.

 

6.   Example 17

6.1  Since the “State” content model provided by “%vstates;” allows only element content and no  character data content, “<State>open.notrunning.suspeded</State>” must be changed to “<State><open.notrunning.suspeded></State>”.

 

7.   Example 18

7.1  since the allowable values for the “ResponseRequired” attribute of the “Request” element type  are “Yes”, “No”, and “IfError”, ‘<Request ResponseRequired=”false”/>’ must be changed to ‘<Request ResponseRequired=”No”/>’.

 

------------------------------

 

Date:          Tue, 27 Jun 2000 10:56:43 -0400

From:         Michael Rossi <mrossi@CRUSHER.JCALS.CSC.COM>

Subject:      Re: comments on “Workflow Standard” document

 

Gignac Donald A CRBE wrote:

>

> Here are some comments on the XML examples in the “Workflow

> Management Coalition Workflow Standard - Interoperability

> Wf-XML Binding” document.

> <snip/>

 

Thanks for your comments Donald. As many of us struggle to commit time to

our work in the coalition, we don’t always get to be as thorough as we’d

like in QA’ing our efforts. Sorry about that, but we’ll certainly include

these changes in our next release. Thanks again.

 

Michael A. Rossi

Computer Sciences Corporation

mailto:mrossi@csc.com

856-983-4400 x4911

 

------------------------------

 

End of WORKGROUP4 Digest - 22 Jun 2000 to 27 Jun 2000 (#2000-48)

****************************************************************

 

There is one message totalling 234 lines in this issue.

Topics of the day:

1. SWAP related query

 

----------------------------------------------------------------------

 

Date:          Tue, 20 Jun 2000 22:12:06 -0700

From:         Keith Swenson <kswenson@MS2.COM>

Subject:      Re: SWAP related query

 

This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible.

------_=_NextPart_001_01BFDB3F.3E5A6A9E

Content-Type: text/plain;

charset=”iso-8859-1”

There has been a considerable amount of debate over the issue of using existing HTTP methods (GET / POST) or inventing new ones.  As you know, the HTTP address specifies the location of a resource.  Your position on this debate depends on whether you see the information being returned as ‘the resource’ or ‘meta-data about the resource’.  For instance, in WebDAV the resource is a document of some sort.  PROPFIND gets a property of that document, but never the document itself.  When the original proposal was under discussion with members of the WebDAV working group strongly suggested inventing new methods, especially since HTTP 1.1 defined the means to invent new methods, which is why the draft defined new methods.

Later, we found this to be controversial and not necessarily suited to the goals of SWAP.  The technology used to implement versions of SWAP were not always sufficient to allow the implementation of new methods.  The purpose of SWAP was to fit into the existing infrastructure, not to define a new one requiring completely new implementation.  What chance is there that existing companies would be able to deploy the ‘standard’?  And then, the fact that you can invent new methods is no reason to acutally invent them.  But the real issue is that with SWAP, the requests are dealing directly with the resources themselves.  Unlike WebDAV, when you get the XML representation of a process instance, the process instance *is* the resource.  Which is why the WfMC has decided it is very appropriate then to use GET and POST.

I would like to see a SWAP-2 proposal put together that is consistent which is: the Wf-XML proposal, with extensions to fill in the missing functionality, together with the definition of how to carry this over HTTP.

*   Keith

----------------------------------------------------------------

Keith D. Swenson, kswenson@ms2.com, MS2 Inc.

2440 W. El Camino Real, Mountain View, CA, 94040

tel: +1 650 623-2329,  fax: +1 650 967-7394

 

> -----Original Message-----

> From:         Praveen Reddy [mailto:pnr_praveen@yahoo.com]

> With greetings,

>       To whomsoever it may concern

> -------------------------------------------

> We into a devlepoment programme for a generic workflow

> engine based on SWAP.

> The problem we are facing while coding on the server

> part is as follows:

>

>       In the document WFMC-TC-1023(dated 1-May-2000 version

> 1.0) the TRANSPORT LAYER BINDINGS section

> proposes the use of HTTP method POST for sending the

> data encoded iin XML from the client to the

> Server.

>

> But if we go on the lines of WebDAV or SWAP internet

> drafts the usage of protocol specific methods

> is suggested.

> Example PROPFIND is method which the client sends to

> the server for getting the properties of the RESOURCE.

> Even the presentation my Mr. Surender Reddy(chairman

> SWAP workging group) has a slide

> which i am sending as attachment.

> The attached slide basically throws light on the

> Method CREATEPROCESSINSTANCE.

>

>

> The confusion is that we are not able to decide to

> which STANDARD to stick to.

> The other thing we may do is to CONSIDER both the

> situations while coding the SWAP API.

>

> I will be highly obliged if you throw some light on

> this issue.

>

> Thanking you,

> Praveen Reddy,

> S/W engg.

> Integra Micro Systems (p) ltd,

> Bangalore

> India.

> mail -  pnr_praveen@yahoo.com

> __________________________________________________

> Do You Yahoo!?

> Send instant messages with Yahoo! Messenger.

> http://im.yahoo.com/

>

 

------_=_NextPart_001_01BFDB3F.3E5A6A9E

Content-Type: text/html;

charset=”iso-8859-1”

Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 3.2//EN”>

<HTML>

<HEAD>

<META HTTP-EQUIV=”Content-Type” CONTENT=”text/html;

charset=iso-8859-1”>

<META NAME=”Generator” CONTENT=”MS Exchange Server version

5.5.2650.12”>

<TITLE>RE: SWAP related query</TITLE>

</HEAD>

<BODY>

 

<P><FONT SIZE=2>There has been a considerable amount of debate over

the issue of using existing HTTP methods (GET / POST) or inventing new

ones.&nbsp; As you know, the HTTP address specifies the location of a

resource.&nbsp; Your position on this debate depends on whether you see

the information being returned as ‘the resource’ or ‘meta-data about

the resource’.&nbsp; For instance, in WebDAV the resource is a document

of some sort.&nbsp; PROPFIND gets a property of that document, but

never the document itself.&nbsp; When the original proposal was under

discussion with members of the WebDAV working group strongly suggested

inventing new methods, especially since HTTP 1.1 defined the means to

invent new methods, which is why the draft defined new

methods.</FONT></P>

<P><FONT SIZE=2>Later, we found this to be controversial and not

necessarily suited to the goals of SWAP.&nbsp; The technology used to

implement versions of SWAP were not always sufficient to allow the

implementation of new methods.&nbsp; The purpose of SWAP was to fit

into the existing infrastructure, not to define a new one requiring

completely new implementation.&nbsp; What chance is there that existing

companies would be able to deploy the ‘standard’?&nbsp; And then, the

fact that you can invent new methods is no reason to acutally invent

them.&nbsp; But the real issue is that with SWAP, the requests are

dealing directly with the resources themselves.&nbsp; Unlike WebDAV,

when you get the XML representation of a process instance, the process

instance *is* the resource.&nbsp; Which is why the WfMC has decided it

is very appropriate then to use GET and POST.</FONT></P>

<P><FONT SIZE=2>I would like to see a SWAP-2 proposal put together

that is consistent which is: the Wf-XML proposal, with extensions to

fill in the missing functionality, together with the definition of how

to carry this over HTTP.</FONT></P>

<P><FONT SIZE=2>-Keith </FONT>

<BR><FONT

SIZE=2>---------------------------------------------------------------

*   </FONT>

<BR><FONT SIZE=2>Keith D. Swenson, kswenson@ms2.com, MS2 Inc.</FONT>

<BR><FONT SIZE=2>2440 W. El Camino Real, Mountain View, CA,

94040</FONT>

<BR><FONT SIZE=2>tel: +1 650 623-2329,&nbsp; fax: +1 650

967-7394</FONT>

</P>

<BR>

 

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>

<BR><FONT SIZE=2>&gt; From: Praveen Reddy [<A

HREF=”mailto:pnr_praveen@yahoo.com”>mailto:pnr_praveen@yahoo.com</A>]<

/FONT>

<BR><FONT SIZE=2>&gt; With greetings,</FONT>

<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To whomsoever it

may concern</FONT>

<BR><FONT SIZE=2>&gt;

-------------------------------------------</FONT>

<BR><FONT SIZE=2>&gt; We into a devlepoment programme for a generic

workflow</FONT>

<BR><FONT SIZE=2>&gt; engine based on SWAP.</FONT>

<BR><FONT SIZE=2>&gt; The problem we are facing while coding on the

server</FONT>

<BR><FONT SIZE=2>&gt; part is as follows:</FONT>

<BR><FONT SIZE=2>&gt; </FONT>

<BR><FONT SIZE=2>&gt; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In the document

WFMC-TC-1023(dated 1-May-2000 version</FONT>

<BR><FONT SIZE=2>&gt; 1.0) the TRANSPORT LAYER BINDINGS

section</FONT>

<BR><FONT SIZE=2>&gt; proposes the use of HTTP method POST for

sending the</FONT>

<BR><FONT SIZE=2>&gt; data encoded iin XML from the client to

the</FONT>

<BR><FONT SIZE=2>&gt; Server.</FONT>

<BR><FONT SIZE=2>&gt; </FONT>

<BR><FONT SIZE=2>&gt; But if we go on the lines of WebDAV or SWAP

internet</FONT>

<BR><FONT SIZE=2>&gt; drafts the usage of protocol specific methods

</FONT>

<BR><FONT SIZE=2>&gt; is suggested.</FONT>

<BR><FONT SIZE=2>&gt; Example PROPFIND is method which the client

sends to</FONT>

<BR><FONT SIZE=2>&gt; the server for getting the properties of the

RESOURCE.</FONT>

<BR><FONT SIZE=2>&gt; Even the presentation my Mr. Surender

Reddy(chairman</FONT>

<BR><FONT SIZE=2>&gt; SWAP workging group) has a slide </FONT>

<BR><FONT SIZE=2>&gt; which i am sending as attachment.</FONT>

<BR><FONT SIZE=2>&gt; The attached slide basically throws light on

the</FONT>

<BR><FONT SIZE=2>&gt; Method CREATEPROCESSINSTANCE.</FONT>

<BR><FONT SIZE=2>&gt; </FONT>

<BR><FONT SIZE=2>&gt; </FONT>

<BR><FONT SIZE=2>&gt; The confusion is that we are not able to decide

to</FONT>

<BR><FONT SIZE=2>&gt; which STANDARD to stick to.</FONT>

<BR><FONT SIZE=2>&gt; The other thing we may do is to CONSIDER both

the</FONT>

<BR><FONT SIZE=2>&gt; situations while coding the SWAP API.</FONT>

<BR><FONT SIZE=2>&gt; </FONT>

<BR><FONT SIZE=2>&gt; I will be highly obliged if you throw some

light on</FONT>

<BR><FONT SIZE=2>&gt; this issue.</FONT>

<BR><FONT SIZE=2>&gt; </FONT>

<BR><FONT SIZE=2>&gt; Thanking you,</FONT>

<BR><FONT SIZE=2>&gt; Praveen Reddy,</FONT>

<BR><FONT SIZE=2>&gt; S/W engg.</FONT>

<BR><FONT SIZE=2>&gt; Integra Micro Systems (p) ltd,</FONT>

<BR><FONT SIZE=2>&gt; Bangalore</FONT>

<BR><FONT SIZE=2>&gt; India.</FONT>

<BR><FONT SIZE=2>&gt; mail -&nbsp; pnr_praveen@yahoo.com</FONT>

<BR><FONT SIZE=2>&gt;

__________________________________________________</FONT>

<BR><FONT SIZE=2>&gt; Do You Yahoo!?</FONT>

<BR><FONT SIZE=2>&gt; Send instant messages with Yahoo!

Messenger.</FONT>

<BR><FONT SIZE=2>&gt; <A HREF=”http://im.yahoo.com/

TARGET=”_blank”>http://im.yahoo.com/</A></FONT>

<BR><FONT SIZE=2>&gt; </FONT>

</P>

 

</BODY>

</HTML>

------_=_NextPart_001_01BFDB3F.3E5A6A9E—

 

------------------------------

 

End of WORKGROUP4 Digest - 19 Jun 2000 to 21 Jun 2000 (#2000-46)

****************************************************************

There is one message totalling 416 lines in this issue.

Topics of the day:

1.   Feedback from Oslo June Meeting of Workflow Management Coalition

 

----------------------------------------------------------------------

 

Date:          Fri, 16 Jun 2000 06:42:54 -0400

From:         Layna Fischer <layna@WFMC.ORG>

Subject:      Feedback from Oslo June Meeting of Workflow Management Coalition

 

This is a multi-part message in MIME format.

------=_NextPart_000_0021_01BFD75E.19BEDE20

Content-Type: text/plain;

charset=”iso-8859-1”

Content-Transfer-Encoding: quoted-printable

X-MIME-Autoconverted: from 8bit to quoted-printable by cerberus.aiim.org id GAA16171

Memo:        To all Workflow Management Coalition members

Subject:      WfMC Oslo Meeting June 12-14

From:         Layna Fischer, General Manager, WfMC.

 

Following our meetings this week, the WfMC steering Committee adopted the following resolutions. Details will be posted in the minutes shortly, but here is a synopsis of the highlights for your immediate attention:

 

1.   Change of password on July 31. For security reasons, there will be a change of the password to enter the member’s only area of the WfMC web. If you have forgotten the current password, it is (case sensitive):

User ID: wfmcadmin

PW: Aelfred

Please take this opportunity to reacquaint yourself with the membership activities and information. Please exercise due caution in protecting the password and the confidentiality of the information found within.

 

2.   Dues reminder. If you have not paid your 2000 membership dues by July

31, you will not receive the new password, nor will your company name and contact details be included in the Workflow Handbook 2001, due to be launched on October 3 at AIIM Expo Copenhagen. If you did not receive an invoice or mislaid the current one, please let our office know, we will s end you another copy.

 

3.   Call for proposals on WfMC “tag line”

The Committee felt that in view of the fact that we now live in an “e-world” it is time to update the Coalition image by adding a subti tle or tag line to our name. We are calling for proposals that will be considere d at the next meeting in Boston, September 5-7. The person submitting the selected proposal will receive a free copy of the new Workflow Handbook 2001.

 

4.   Suggestions for location of next meeting after Boston and a sponsor –

The

Steering Committee decided on Europe in January 2001. Where would YOU lik e to meet? Please send us your ideas. Traditionally, a member sponsors our meetings with respect only to the meeting rooms and refreshments and we invite offers from either Guest or Funding members.

 

Layna Fischer, General Manager

Workflow Management Coalition (Wf MC)

2436 North Federal Highway #374, Lighthouse Point, FL 33064, USA

Phone +1 954 782 3376, Fax +1 954 782 6365

email: layna@wfmc.org

 

------------------------------

 

End of WORKGROUP4 Digest - 1 Jun 2000 to 16 Jun 2000 (#2000-44)

***************************************************************

There are 2 messages totalling 88 lines in this issue.

Topics of the day:

1.   SOAP (2)

 

----------------------------------------------------------------------

 

Date:          Thu, 1 Jun 2000 16:19:54 -0400

From:         aglacet <aglacet@IMRGLOBAL.COM>

Subject:      SOAP

 

This is a multi-part message in MIME format.

------=_NextPart_000_0005_01BFCBE5.38862D10 Content-Type: text/plain;

charset=”iso-8859-1”

Content-Transfer-Encoding: quoted-printable

What is the link (if there is any) between the Wf-XML Binding and  theSimple Object Access Protocol used by IBM and Microsoft (among  others) ?

They seem very closed to me.

thanks

------=_NextPart_000_0005_01BFCBE5.38862D10 Content-Type: text/html;

charset=”iso-8859-1”

Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.0 Transitional//EN”>

<HTML><HEAD>

<META content=”text/html; charset=iso-8859-1”

http-equiv=Content-Type>

<META content=”MSHTML 5.00.2314.1000” name=GENERATOR>

<STYLE></STYLE>

</HEAD>

<BODY bgColor=#ffffff>

<DIV><FONT face=Arial size=2>What is the link (if there is any)

between the

<FONT face=”Times New Roman” size=3>Wf-XML Binding and theSimple

Object Access

Protocol used by IBM and Microsoft (among others) ?</FONT></FONT></DIV>

<DIV>&nbsp;</DIV>

<DIV>They seem very closed to me.</DIV>

<DIV>&nbsp;</DIV>

<DIV>thanks</DIV></BODY></HTML>

 

------=_NextPart_000_0005_01BFCBE5.38862D10--

 

------------------------------

 

Date:          Thu, 1 Jun 2000 17:59:38 -0400

From:         Michael Rossi <mrossi@CRUSHER.JCALS.CSC.COM>

Subject:      Re: SOAP

 

aglacet wrote:

>

> What is the link (if there is any) between the Wf-XML Binding and

theSimple Object Access > Protocol used by IBM and Microsoft (among others)

?

 

Right now, there really isn’t any. Wf-XML and SOAP were being developed at about the same time, but by different people for different purposes. While Wf-XML messages can be used to interact with and control generic services, the protocol is predominantly focused on interactions among workflow systems. SOAP (built on XML-RPC) is predominantly focused on interacting with and controlling generic processes remotely, without regard to the application domain. A very subtle difference as you can see.

Several other XML protocols have arisen recently as well in various application domains (content aggregation, distributed web services, etc.) that require some basic framework for the interchange of XML messages. This evolution has been recognized by the W3C, who are now evaluating the formation of a formal “XML Protocols” activity within that organization.  This evaluation is taking place on a public mailing list called xml-dist-app (accessible through the http://www.w3c.org web site). The maintainer (Eric Prod’Hummeaux) has established a matrix of the various protocols under investigation, which includes Wf-XML and SOAP (among others).

The WfMC is monitoring this activity, and plans to enhance our coordination with other industry standards as they (and the Wf-XML spec) progress. Sorry this was a bit long, but hope it was helpful!

Michael A. Rossi

mailto:mrossi@csc.com

856-983-4400 x4911

 

------------------------------

 

End of WORKGROUP4 Digest - 25 May 2000 to 1 Jun 2000 (#2000-43)

***************************************************************

There is one message totalling 550 lines in this issue.

Topics of the day:

1.   FW: Invitation to CEOS/NASA workshop

 

----------------------------------------------------------------------

 

Date:          Tue, 9 May 2000 11:11:17 +0100

From:         Hollingsworth David <David.Hollingsworth@ICL.COM>

Subject:      FW: Invitation to CEOS/NASA workshop

 

This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible.

------_=_NextPart_000_01BFB99E.F58E4670

Content-Type: text/plain;

charset=”iso-8859-1”

Final call if anyone can attend (Lanham, Maryland 17-18th May) to represent

WfMC.

Rgds, Dave H

 

-----Original Message-----

From:         George Percivall [mailto:george@sgt-inc.com]

Sent:          05 May 2000 20:02

To:              Allan Doyle; Brian McLeod; Dave Danko; David Beddoe; Dennis Smith;

                  Dorian Arnold; Doug Nebert; David Hawkins; Gail McConaughy; Garth

                  Henning; Guenther Landgraf; Jeff de La Beaujardiere; Karen Moe; Ken

                  McDonald; Kevin Farrar; Lee Elson; Liping Di; Lola Olson; Miriam

                  Goldfarb; Ben White; Lou Reich; Sam Bacharach; Johnson, Sara; Steve

                  Goldstein; Suresh; David Hollingsworth; Tim Maynard; Yonsook Enloe; CEOS

                  Data Services Task Team; Kurt Buehler; Henry Tom

Subject:      Services Workshop Invitation - please RSVP

 

 

Invitation

CEOS/NASA Services Workshop

17-18 May 2000

Lanham, Maryland

 

This message contains the Purpose, Agenda, Location, Airport and Hotel information, and Links to Reference Documentation for the Services Workshop.

Please RSVP to percivall@gsfc.nasa.gov

Thanks, George P.

_____________________________________________

 

** Workshop Purpose

The workshop will address Concepts, Technology and Applications for the interoperability of network accessible services for geographic, remote sensed data.  Of particular interest is user specified combining of services to create value added products, i.e., service chaining.  The results of the workshop will affect the further development of ISO 19119 Geographic Information Services and the OpenGIS Web Mapping Testbed 2.

**  Agenda  **

Wednesday, May 17th

9:00/20 min          Welcome/Introductions - Ken, Yonsook, Suresh

Part 1:  Concept talks

9:20/30 min        ISO 19119 (Services Standard) Overview - George Percivall

9:50/20 min        OGC Web Mapping Testbed Services - Allan Doyle

10:10/20 min   GCMD Services - Lola Olson, Miriam Goldfarb

10:30/15 min      Break

 

Part 2: Service Chaining Technology Survey

10:45/10 min      Introduction - George Percivall

10:55/30 min      ESRI ArcInfo 8 - Dennis Smith, David Beddoe (invited)

11:25/30 min      ERDAS - Sara Johnson

11:55/65 min      lunch

1:00/30 min        WebWinds - Lee Elson (invited)

1:30/30 min        Facet Decision Systems - Eric Lanning

2:00/30 min        Khoros Cantata - Kevin Farrar

2:30/15 min        Break

2:45/30 min    Java Advanced Imaging API- Steve Goldstein, Garth Henning

3:15/30 min        NetSolve - Dorian Arnold

3:45/30 min        Workflow Management Coalition - (invited)

4:15    Wrap-up the day

 

 

Thursday, May 18th

Part 3  Current Applications

9:00/20 min        Introduction - Yonsook Enloe

9:20/30 min        Digital Earth Applications - Jeff de La Beaujardiere

9:50/30 min        Global Observation of Forest Coverage - Ben White

10:20/30 min      US Army TEC applications - Jeff Harrision

10:50/30 min      USGS/FGDC applications - Doug Nebert

12:00/1hour        Lunch

 

1:00/      Part 4: Brainstorming Session

*   Provide feedback to the current services modeling work being done

*   assess what is there now with services

*   assess what is needed but hard to do - challenges

 

 

** Workshop Location

Raytheon ITSS

4500 Forbes Boulevard, Lanham MD, 20706

 

ITSS is located at the star on the attached map.  ITSS is on the East side of the Capital area.  From the intersection of the Capital Beltway and Route 50 go East to the first Exit to Martin Luther King Parkway.  Go either N or E on MLK to Forbes Boulevard. Turn right.  ITSS is on the right.  Ample free parking.

Wednesday AM & Thursday - Room 323

Wednesday PM - Room 427

 

** Airport and hotels

*   Airport: closest are BWI and National.  Dulles is a 60 to 90 drive.

*   Nearby Hotels:

Holiday Inn Greenbelt - (301) 982-7000

Marriott Greenbelt - (301) 441-3700

These hotels are located near the Capital Beltway, a couple of exits north of the Beltway/Route 50 interchange.

** Reference documentation

The workshop draws from three interactive activities:  ISO TC 211 Geographic Information, Open GIS Consortium Web Mapping Testbed and the CEOS Data Services Task Team.  Listed below are links to relevant documents.

ISO 19119 Geographic Information Services - submitted to be a Committee

Draft

ftp://lyta.gsfc.nasa.gov/outgoing/percivall/CD19119US.doc

 

Open GIS Consortium Web Mapping Testbed 2 RFQ

http://www.opengis.org/wmt-2

 

CEOS Service Chaining Technology Survey

ftp://lyta.gsfc.nasa.gov/outgoing/dstt/ChainingSurvey.doc

 

 

 

 

 

 

_________________________________________________________

George Percivall                                SGT, inc.

percivall@gsfc.nasa.gov                    (301) 614-8600

http://sgt.sgt-inc.com/~george         fax (301) 614-8601

7701 Greenbelt Rd.,  Suite 400,  Greenbelt MD, 20770  USA

 

------_=_NextPart_000_01BFB99E.F58E4670

Content-Type: application/octet-stream;

name=”ITSS.jpg”

Content-Transfer-Encoding: base64

Content-Disposition: attachment;

filename=”ITSS.jpg”

R0lGODdhigKQAecAAP///zKWSwAAAP8AAABL/wAA////zr0AAABkAHOEe6mva8yZM4yNcP8A/0JC

UhQUzbTS//+AwHp6ent7c/+5ljEAnMZW9f//VXoA6KbK8AD/ANrQZMDAwMnewq3No///zMzMme/M

g8yZmdy+tN+/v5O8hcDcwJ9O8cXF2pnAi93d3f/MmYCAgM7OrQBjAIBAAIAAQP//AJaWlpnMmd7e

3v//a///pf//mWaZZtkYE68UE96NITOTUABPJ3+fv+Tky/Dw5NrQtJ9aLa2elv/u6PTNipkAAJyd

gv/76IWFhYKCgv/OnP+gc6zN+P797ODPfJmZZtxkZNKb0rS0tPDcANwAAADcAPAA8PDw8PAoKGQA

ANzc3DzcUBTIPABQKCgo8AAAyAAAZPDwAMi0FIx4ABTw8ADIyABQULQAtDwAPGS03FCgyDxkjHh4

eGRkZCgoKNy0tIwAALQAANyMjPAUFKDcoAB4PACMPCjcUACgKKCg8CgoyFBQ8GRk8NzcoNzcUKCM

FLS0UPDIAKDw8ACgoIzw8PDI8PCM8GQAZIwAjNwA3Mjw8FCMtHjI8MjIyDw8PIyMjKCgoFDIKAAA

3MgUtBQ8PHhQPKA8AAA8PLQ8AHgUALRQAFA8PLR4AKAUALQUAKB4PKAAAHgAADwUPAA8eBQUPKC0

8FBQUACMAADIAHg8APAAACg8PPC0tPDIyIygoLS08Hh43DxQtFBQtHh48Cg8tIyM8ABQeACMtPDw

yGSM8ChkjIyMyGRkyAAA8PDIFPCMFMi0jIw8AIwoAIw8FKBkPMgUFBQUFLRkAIxQAGQ8AKBkACgU

AKBQALQoAADwACgAKNy0AFBQKHhkPGQoALS0oPAAFAB4jADc8ACgAADI8ABkZCgAyNzc8MjI3LS0

3KCgyLS0yMjI8PBQUPB4ePCMjPDc3PA8PP//0rnCvdbm0bV45pRPv9rp////54CA/4NHrPj48tbP

y69y2qxHhZBl7JUKfqoMfj0oiFdKnL2A9HdCspdp9NPl+MbGuKGhqSwAAAAAigKQAQAI/gAT2LAx

rgo5gQNttCqX0EaCKuVoSEyAcKCAAwfMkSNX7iJGAQ0dmnMV0ty4ig3NldtYjmTIkOSylDtH7lwV

ByazVKnysmdIij6DCh1KtOhPo0iHojS6tGjTnk+TSp1KtWpUn1eZUsxatevWBB7Cih1LtqzZs2S7

BuWqlmnbt0IRatRpbuvOkxQLVqmLcJw5ixjJ7dxJztwBAa5auUxQLsvfhILlPiY4eKfMgeZaaZ58

zsY5mp01b4ZLunRc00TZvlR9NDXq17ChJgUq9WtsqxTR6t7NW+xr1rGB345bMcHIhDYNJqAx+OTA

VjtbAdZrTmeWA4Itu0ogmGHCnQmS/g+mvPPcaL2VB3Y2X3O4e7jC38Z3OFX1/Pf4VyNFSJv4Vvr5

+QdWbwQWmNZvAeqXYG39oSReOdAN9ph40l2UXDmDRViZSjs9hmEVD5VXzl/mPPiYSjpVkYVLAzng

03ELxpjQfTPORlVFBhjQkI4Kuibjj1jth9JXRNrWmoxfGajkkh5IlaNSP9IY4EbktPJYReJVRpgN

5qj44V8CiEeTZh1+aGV5mVnWpUGTPYceOQmtGZKLIc00GItA5iclgG7VN5ABAgiQY46C9nhanojW

6NSeAzF6Y25MRmpgUoAKyiNUjtaX6Z+DPtmpp58SVRNNhTm0VZZaZmFDdmuOY0OY/jsd9uoBO620

ZYqVVVmZdDBliBxPNjggLJ0vJdZmosMxKtx9OAbqbKFHHopsnqxlumlqW0mq7aRIAVrppYbqWRqh

zg76rLnl6vjpk43O+JVEgmWn4pp74eqrTeXIehF60Smk5V4ajsPrQK7wO5lgCQ3r47TBqRUfswmt

C66iUDIMpH2lXYsppNt23Fu3hRI6McXimhYoud9+e7LKKlvarrsSSQTdiLUOVOtg5OilKoaGgfSq

hjX7q53Q47BE4mDnjNgQdAkHS6c5x5JsccYO13bjnyuXG65sU0e5MHywZevx2ASC7KnLIa2Ln8af

npy1oG+3/O3LrdQ0TkQ0GFcF/kk1TWZQFX49t5MrgWKkL3ZaTgZ1Q6lG/VKXJAn7EmF4mtq1aXsu

ezXWKEPbEFsaX75fxVSTliTZqJdNlLduww0uuW8/K/vstNdu++24B9pQunH3DvfvPAqE4d0x5z2U

SiXx6pG+F9UNJ4RBzcSR4y+26JMrOsH5+XtFdt9f6V7Z6KcN3pIfsucvSyt6gFd9Dz5uHKcu/26r

ryz3jr2jo//+/Pfv///+SwcAB0hAkLQNeHKTW+sutZyYUWQialne4T7CJ65RhVjiQ5T3NkiktbRF

c+MrnwjRh7H1Jegp/wkb/ObHQtUJpXycqpTnUuY2AtrwhgK8oQ715zPfdc5S/gtcYKMc+EAIRtBw

IJGgALJCI8ltzoQCKlJQRmZBpzyRdepCXwWDBEX2uSuFDRNS/FpIRrQUZWI0VBcN4bbDNvIvh24s

IPlkaCk6osuHJxsIEYvnKCXO6iNMlIrkMMigLo7vJTDk0cTmw0j8ZVGLoDOknsC4NmyNsYyYNAtV

Rigy3+Xuk6AMZe1iOKg5dsqUElObDSbSwLxtanlJNNxh2jcVhYVPkqPribdEBsP05TKDf4rYyCKJ

S/eErk8R+2Iml/kxSp0vi2sEVBzbCMdp8rAtoVJKK11ZGljGEpAeFKQtrVLMrzlybp6aYyOBicxw

ljOMr6EiyQyAAANckkCd/tqWAZg5Fic9c5d2lKY1bVjNgfpMbQiVWLrYBRUivgaWfzyMz6poFELi

5p3uTBvwzNfJkDGUfKf5aEbbSVGMYg429HzdpexpzwSkdJ9iyVFMPQBTmMYUATitJ01tuk+e2nSn

NK3nTzM5FWhytI6lFMBACbrU/RkwoFA9V8pS5hOHPhSJr4LoSIdi0VuaNFr4cx1HFWi/RAazUVQF

6WqeslKwlvSrYItnPSOGU3XVU6cp1WlQ8XrXHOk1LC/taV2DmtK91rSuOf0rUTcJRF6ai46ijKxk

nWU+ICJwgZCdXVC4GZvCUVCrXCyKE00H1+3psrFj/SfsXLdLaLUWtW4d/msvt/jW0lZNrioVKmL9

2lfAvhSxvQWsUAn727r+1q8yfSk/m1QVaP7ObW2Tp9VIE00fJjCta3UPRP24VZ909YO2vQonW2tU

lnXUteidm1tZl0fTqs+28kHpXClCT+PqFrmFre99j3tT++J3uPrVLV+HukxsYpGX5dLiE+Gy2ss6

GJ3t/ZEfQRvaoHz3g8dckHjPx9p/xg66r0PqbH3JOSzG1r3wjStqUgqW47p4vzD+L08BHGPhDkq4

911uWBiswE5K95c8Rld1LQthBS9ou7KcaG2dNlrUZPiEL4xYhxFcRxErWIYi29pRR8yVJ39VY1sJ

7ItlPOYx3/SwMrax/kx3ul8dj4tlAgHoj0nXTSJbV4jYldGEsfrehowTQV/ullqdey6palGN0NUy

e0lozhTf1mFi26t9+xrj/O62xjbur2BnPOnDKnax4xJry2bIzres9o5V5p1HdYcoJFOwKi5qspNN

6r6iolLEHHVknMWK4h1lU2pLdvR0HzWgsuQTqD0FrLJpGtNk13TZMx3Lmtfc7Jr+lNrMjGcaq2xU

K2r7lAlNJSlbjUTPvrqW3PNyssCbNl1q1M7QoqSUtXZiYAubnLOJ9JJujMn86lhJKE1w1lC2qHvD

xtzflBW6K/lOZXUFZWo00mkf2+tgG5ykWNF3pPRr7Zk+W9kfZ7bI/pMNcgBD+99liY2PsbxLb18c

Na4+d0WhXE5lSZxSDKw1Il1bb3u/vNTKHFtgcbzpHOcVucS974ATy1+Up/w2LG0seX+s858fEasU

Fq2Ga87uRm1Qm1Xf+SkrrmWrk/R0ZCvsmYtbX7bv9sV9dXHTnd5P92A5te0dptlhjnU+czXWMQp7

1xxVLQ4K/t3n8jnZ925FtMtP7WqutOTJPPmkE9jp3Cvl1Mn7OXUbXInc/fuF1y1Jm6vYKKokscUZ

v9Z7Pl6xZZ587Cm/acjT3YslfmaEacv6q09Q4UT5M+676HDSgmz3vO95700FqWL3W6i1l/3k/Vtm

w9J9x1vnVHrp/m3P5ZPGm6G3MLU8b3yvxhf13F68+g3M0DkjSeMecP7zB9t2y8+esJVve/2vz1ya

s/yyWeZ9cBFzStYTo1cyJkR4J1U/isRodBZqWjNiUQJ/ZCF/ZcRvQLVsH7eBHqeB0JZcn4Z5gXdU

A7dlAvh9fSdzBogs5Nd15nd+DBiAqld2aiFnRDaBrmcWFsh/O3V5xhaCZrF//BclcjZeHuV+JxgU

CBd+c8Iw4pUoCvg+LyQ7DDQUOYIQSKhLH1WEuXZCFMgbO3h9HNdsHehvu4FtQ4gkIeZcj3RoSWgU

BOhdQBYcbGVkNOcVocMWErN+EEZFpYRKbRhi3GeHmJNCPJh2/kZHf3GXY4foQu+XTJtHcZzzhkQB

eknmZ8LXZyr0bll4G8W3gFNEO1UYis8UQ5VlWQkmiYBYimEjbzbQiB7TdP/lX0AIi5qkQc3yWok2

iWplap3YRXGIiQeoeIA2R8iHJC4ohYgEUJ6TFQfGYazFXo41iA3Ybabjig1hi/qUU57WZkKojbrB

grSBYKrYhw8nZClmiR+hZLE2jMnnZAKxa2ijQclYfj6RSM0YiuTIjLpHaDLIjI/0ixvDGuAoKcpl

f3p1dAVJP9MCFC5VWeqVaxGJc1IlbMEYLMPmiTMykfT4aKCojzK4YYUWgJzUjxN5d5yiKTdnFAvJ

JJBnZpbX/pJnMTX9QXBS5mNzdHxjZ5HlplXuuH7wsRQSSC31aI+nlXgzWGLPyIZTR2Sz9YdaIUVt

IZNKYnttF1yW5oMLSZNCiT5YxGGdCFUWCX5IJGuN9pEbOUMCiZaaAk/3+GvvWD4u5ToD14cipEj5

JpWvQZVVaWzOJm3Rxpd115DudpNSd4xWeEdraUIE+JNAiYcgaZMj6JHFKHYV5kjtQmWu1Va9GEUd

FCCCGZrL5YR6mEfSWFSnxpPldomHlDFcwXJDyT1FqYw3CZVJ2Ys4YopR6T3IIpq+CWpQiH6BaEro

V1afl4LAB3SQmRpLiYyUOWtHiZS3+Zhe93Um9JvY2UIN/gkcw4mSU4hUL6eOKlhwQWk2LDeZLwid

WriT00kyhvdV2Rmf8sOCRWWanTKPb1mRx/lZfqec+VafvLOYz9luOxJbYamJ8yYohregh2dS8vmg

YwOF93E2qUiIpMSR8EWW40meF1Uf/ChSxlR1ItSFVyhMY6WbOXmiOcmgAEmJQQGhMKotwVmD3Dai

RwkqF7eEWYdxWkGjPySgm3NzTRmQWPNcqBiQAYWYGlWNLuoTMfqkSzKjD4dZsOVIvBaeZbmjHFqY

P6EsvCSRDNd59HWY++gyAJlIm1elkWmhbwilbuqIXmNgdXmMzYmlq9mfcyhMJLQpcaZ9MuiWE0eX

p/Yt/nMZdSIzlyVoR4lJhU3aE2/6qGYkpdjUWPhpmH+6n79XgD3qa/RmOaUTTcbEgBJZR0WaZUPK

eQBlhTXaqI4Kqa7qG/RJXRBJip1qp+tYblc0VYVyTGMKcbLpE7rDSbLlpwA5p9Nom5Y5q6waEq/6

qoRpGpe6pMhqq86Cpz3KMhz1ZHF2P6T3EgIAAAAgaugVN6VqYuYVO/IUkbHZpM0KqU4IrUq6Iw0K

X8KyhNbqFkYIpE7Rcut6ersDruBKasKkSCrlpylJsCiarDe5rNnYrm5qMaEDousJl/dWr0nGmoVU

jf0aXwTLprP5rQCrqf7kscK5sAybEA4LpTQpI5kV/q+lFWvedK8ud4oke1vopK8I+ioBy2MQeJ84

+3MpG6ODp4ZS9bOi40RKhLHTNVVGqxQ2WLMZ6a0iiyyQ1bQvF7QPejkt+BOg+nIYFLMbakVFZrVB

AnEbu2DlRLEn+4qiiRQPq7WBh49kOy3D8rUXK7PMmWpzW7ZTVplr62i+iRqCuT5b+zk2KLEvK2tg

m5z55qt7qx+6uLeFe3GPCxuBGxtbSbhxWzuVCyTtuDt3K1EJCyVyK5t2BLU8+rcTZ0iXOxy2mIDI

KG4VC6x3KivniS3R1Lleh3eIi28ni4RPyZ6J0rrvwYNQNLk14p2zS7tIhERdS7q6qrv0IY0uG7X3

/qa2+ohIvdhLVcswxJsfIgi7m2tiBjd6sGQ4LdeFeeuzlcSvqPuAwta9q3OXbMiLEHm2oNm2PwJw

AyEphoS8aNW3wnaASfuUNSuP6fKrDVi9eepocjawZ8WUqrZSeceKvam/edJMDcstxEe0nDfAldi8

rGOyYpuauouFLQqDBvfAp1imB0a+Jius0/K9GXyLrQqn4qthWMbAkpSJPRGz3Au1uYiTDaNe+HuW

KVa1xfqVi1aCtVmnMxyaXTOYL8obxQTA05vAjubD3irCK3NWo3OXPFw1oPK+3eXApFqSTByN1kiz

5JhuvMmsUlxa4XjFsYu9X/W5QwHEU2U1kctw/hianvE7Qx4mqEs5YmOHlyrJoPOKsnNMxzaMS1iM

qNJpW46JcOgrmfhqP+KSvhDsuyvslYeJWoumyIv8nreBwbZ1IFw3gtGVYo4JGLf6f7+4a2rUuyc1

Msrrn7aFyBWsLpCIy2LaPRc8uMKGfQ13x6r4slKByeT1vn2qqL+qpxvVmiushQW6m3opOqqsusN3

QpklvfkRywnhTdwqPoebbpaqvtZLiaiMUd3szWFqhbmMx+9EzhZxvjYpkLZsv6SXr6DMehx0tY8s

zyXzOhFsxmcMV1xcFPpsZbUsW5WqkQAd0Ck20N4XzwYNdf38xkecugxtlnB4sajGzy08xhiW/lrA

LMgSyshxzKoavdHUxaSvJY0fPbOw7DRVAUuws8w+kprtS8rC7JnEzCAuXdQyXRQxndQ0SmSFeqoK

vRaya1L4HBLLI81mJbb2E9V+UmRRDTpHjcXyPJ9MLUnPbKoRiNLFOTviHBtV3cUY8VhmS7Io7M/J

sq3GyNXvWNbrQzZ8DUWCeNY1Hcg+mnrlJNJTUcCGdsQ4ctMwmEYs/dfcvC2SnSjpys5LSakBumJ6

bTFv/cPNewD3Sap9QtjrpqtfLdaVLRX+u9qIIoFMHFZE+sCOLaqW/Nlw/RFxvdVC7MnZ7ImFutUC

qtquzZL8W9yvbaaap6ZjC8bKGmptPRwN/r3Tof3HYayFne0aK/fVyJ0ghn3DVtzddud+O7zZBoyw

b4lS9gxF053Yd9vH1tvTpnukQ716+DHV8IXQAhnOIDUy4S3eUKfJvibX3GbBYAzA/H3POt1N1b2Z

GTnX0gsUp6vW7XnfnJvE26fLEfzEZy3HkQzgKidwt9yGfWuuhIjFr3zYnSVLu42O6PzF7BxGH9qZ

OM2yNZrdqIfHK/2Lckuw0PTBJKqm/cvKIG53ZoqKUrePqJpxKM6+Kr7iui3am51L5x3U22bSeVLR

Rs6oSyrk44aZzzinV9rjCgarRZ4faXSsi42UVGQkCM7WTw7lstThNlLlQd2P7ezdHhbd/um83CN6

y258TmT6zGOeXrV95gEXRD/+WLjWeigUI99tSLjt0F5czTQeTuncyatW38r3HrpI4VPqs7RMqTvs

05ltaIIaw16O6JB+5Etso12KjdQJqD38HhIU10bM2EVqml6EpItJ3C08rVBHhVeu2TjpyyMEnpD9

xAbO6jbus4mHoSuJxNPcw4jNd7rNr6bdI+uC42Bny7tc4wuSZ2iut/1I6iboy6ZZ4swtndHt7LRq

n+2Xc41s3624ibDR3gPI4qIt2uT+NfLdrSicfv/5I7Gt59W456Q+pMlaysl06cIL78kt7GLqr3c4

RdZsGno8HOcr5RNNntFLh0dRunlu/uFAbvK5R44Lj+R+WKAUz3hb+LvYop7Zl728rBaT3sz8DttU

LrC/0RT9rKINXO4n7+mGntaCfYTebnZMm48GXe9DP88KC9JtkfM6H+WAwqlZOI6Yco0exPA3P+yV

jObZDJU7PmiBbklIvXcJvteNCvVhT+uynShWf/WHwWcBL+67W56YHjcR/ewvb0id4tJNuofE2KTq

ptpREe4Z59Z6xu/+Tq6b6i4Fb98ofM5ILM6RfjFhDezvJMOH/4Zwn/HDxy41PfMaD3iPj/WJ5tgO

ySzu08hDHOPwe+jHN/auGdaXWdn46IAnO/poC2XmaNrAL1rXrl23ruWVT2yy7k4d/vv38yZPR52Y

Pr0oDGqUkq2uTv/7W6vaHUWSdlj8FXX8HO/FJP7uUniSAH8y1mn9LBr+7V/hs1nWyC7/3je5Yj38

q+72cFH3O538ACHAgAGBA20cRJhQ4UKGDR0+hHgwAUKCBikKjJhAY8WBFiN+VDix40gDGk1qBGlj

YkqWCFe2hBlT5kyaByteNOCy5k6ePXX6BPkSaMSbAwVgJHg0Z0ihQxE6cApTwAGqU5Mq7RhVa0Kh

Sy8qhSiy4FGwThNcJVs2ZlOzW92+jZl0JEaJcO36RHn3p16bSv0i9bj3LVS+DI9SRTyXrNfCNdna

MCqQ7kO0HScDPVvQaGCYjzE3/gZtF+1lz6FNSyztNrXbqznlMswLl/Dpg1OrJpa8mfbaha0hX4ZN

Uu3QzEtvOla9W3lPkiGXK1+dHPTx34xR651N+zBiqhxzP2fZ9a9r4M77arbOM/PY8p2lg4ffM3p8

rfO32t+Z9bzX9PhpOoAqu91sO8A278BKjz6uEiqKvQQX5Mi3zypT7z0FL2zJPwx30pC4Dj/ySMLq

GopNNgDBI5A7uTRrD8OuvmqRq9G+mxAr+SzcMEfIXDNPRxxB+xCi1yKc7MEg/zvxuRQTc+01H11i

S64HnSPJSbwqohG5+57McUXGjuQyo93AdKjBzSZrqsS7kvxITa2WrCoy/cJs/kpKzki0SUqzsNRN

y/rCvJBPNAH9c8yoDhzLK6HctEvAjMgECU47h8sRJfEiQ+ohsRwkjk/qZoJUU0Lj8466UEft8TRI

+TOoVCtXYrRRR9s81SFJ2YuRvpfqJPJTpo7zlcPRpmSQ2FphQxU+QRVNFq/lyGwQK6Rs5CrWRmmy

lqdb0SP2rTtJTJNBukREtsmyuk2puDnLtHKhbP1s9jTy0mI2Xg6fA9NVaZtE1rRZOzs2oVuNo/Qu

PUXtd0Ry+9WzT+SqpGw8hwJe0F7TIhypYotBxZcmL6Vs8d2tTvwX4De5OyBadA+VrODr8NyP2rA4

2jFLbGd8cEiaIbNJJSE3/gYUy7QGBVomijmWqbUzXfb5NABLXovigdFrDOPyontJznR5lvNb3oTL

+bLNShVpx2LL47FoUnfMWDC1t+4YpgNdhe1omJ72cKht6eXrYOtErquvlX+aNFe4W23R19b8Wtpc

YAUHzuu4nxy23rfDA69D3YaFeTeoOax1YIf1UjpVMSlyD9HBxbSzzCLHZlvoFVu2jLxPW1do9R83

JLIsu+nM3D8+Bf8W8DXfMv4jScfWXaWTnof++bPV6hDMlZQuSNjcYqTZy98WM3Paj20W+nXD7fqd

ZYJ1S//J9t0DyfZEwQXvc7xC3XsxpqI3yeiT2HZbuoJ0PfTo72a5CdZX/kBmu1JVR3xzGR5Oanem

5kXlfUPpVUUuqKMNwo0oiVrYy55jP8xAannNYY11TAUvzKkugenyVK5gF619ObB29Irg9yAoMdp0

kDlDu4kPXRSf1VgGhHdKHnaABCY4FciIFUzJwaozkVAlMXDYe2FQOEcUBlHkhmMDIgizhDMzOWVd

YQlaxpYixAux8XS9kVPLQuZGh5AsNFZUyN5Gh0HwjehYSUSJ1YLIP0KeBGOFFN5ZFHZD8I2xgJs7

H0swNTg6ziSBlYQPJieWp/Mkan5M0Qt+8DYUEoqwJaKzmRkXt0azGO96WisJtAQIvU32LHex2x5/

xnXESMYPK1nUmI8w/hbMywVFVzrMIILctUGN0IAlo/RJduyHRxssaXZnVOVr0ieyQP4SihaMXtPi

xzVxrW+L+cme4N6oI5wFsJhopM8Ed7lH54UyATRwJkhKebeElNKKy5NWL1uiQlYiz1r3LA7fFMS/

pOEEl9/sjdjOp0m5oTBw7zTmc8zlyfXxDJR3uSc+8/mRfUKEME9DKTTDoiFrskigkmyPDwkp0vV8

0mNVguhKpTfQ3vjkdoajqNxYZDmMrpM2shOfTatlT5rap6QmHaU0baDSieHHmrLzKFAuCR18JpSe

Ax2aAeHC0IsVCahhKt+XiprRoyITgZxaZihFSoPkPfUhbJpqP/X6/qiUEGhuX7WkzNzZmJCqS38Q

xRhgQRpO0SBoolwqFWnW2qbdmElf2KSm/5r6zJ6QbDZQ8+d8UjSjl/pSZpk1Cz45B8yIMYa1S6Sl

KlFn1C7lcrCTNd10ahjDBKG2i4/aLEkDxBM2lRKvmorOdroDsWw6KagS6SpOxQpT15bWNIy9ae1o

G6ilEQ23CJuO/MAIu4+i01gh7WpLqMrZvMoEpZSFCJwEwBpv3pawhc3TL5PmTaZp1ZY5LRt2QQRE

+NYWiGr9LnJ1K8bw9Yc5IwJXcNV73JSs95kUrqWt5KuVuRGzh+m1U04rxxNsEk+pXLRJcer2P8pA

cLvx5K93E9y5/sIscEjphBKJGwibuVLTrgrBcIWHG5TVbFh9n/RtaqMrR+sWq8RxEatFGmicrALQ

oUXx4mwpEtssS87D3AUfgmdM4xozToce3dUPd1ytpuIxyPq0MD/Z2hDlIma+ZnxrQTMH4kdCkbnm

VVl1LrtLtVh2WuLjGnAMyTgWJ0yYWrPvjDEpIc5QMVTy9FUzuworObv3pJ31IJ1RViBV1vCi+OLz

+krbTkAz+LLjc5ihx3vZhvAWNYjsH4YUI+Yxu+uo081tFMX1HRGhl67BruOPD/LmmeyzyKMmtU8D

ymtU07V3TQYbiQ/ram6Pt5wCMWwjvc2QyFYQkfKqzN96TWbd/nbrQ8Ba5Zk1TdfHiLLZWinps1F2

55owULDPdRef+9jvJkdU1q/u9rdL4irxplIi5fYQIenLLXWv29GhQZfwJIireRo7VtF5b0yUTVLM

PUS+/N7v5j4FcKYs+cmR/i1NGIfwWTOYUkFkuDpfWNP+1kfi6AwrtS1+6iEOmGAcPZdAegzPuzK7

jm7Jt765g/L9Jp2oRARx7nqrFwEAAACGfmDCc6hOFfumjMHhFr4EHL8/i3PoyM7kfIpyY83gZNMF

bkiA9mnHkeU7vqOmetIW+OVqH9uLLmufRrru9a+bpCRm+2/ks0pPVrKKP1r2tRELvlguw+/tcM+k

Lwe/choY/iC9RL6ryJ2OpDj7+u/7Zk67WE6i0+uwYNucyOK9TnWyCqnnVYw3oH4O3s/DfHIRy96Q

oCThOQPZvVMdOclLbivA5ydCoH/W6buXaZ8LbPdE7jwnic+xrLzWfQKe/fFd5Jnq6vJL6KWmZ5Qd

/QpnKCJGrvp00097a0v0bwFjlKNwjLVzvYdxsXfqveLbPxrrqP3QsnkzPKNZiPk7numjPtgLrCcy

Pq7qv/YrQPUQot4DvqCTtFz7vAVkGLhSp5a7O2xpih+jP/ayQFHDQChrFaFbKJH6KQeLqwx5rkbD

ltjxsuKbLBQsQKxyKK7osSpattXLuzWxq+SqPigbOKLb/pDCur6dEQwTtL/Qu5ea6TkiFEPoMDEV

YrMWJCUndL7BGDLPu8Cps0FIc7tKoSmz4z4u9EEiqpBJyakx9MMtcaA5Yj6g0LsLkxVlk8IaBBFk

grw55CAQu0FKSTJHJMN7AZbN+8NMbAvb662lGxlDjEEh+7FEVMTWmiQcvMLa65oPRJrMuRFB6kNN

lMW4kBEbYkF6g7q7UUPiCsLXg8MPQiAJMUJNETg5tEIJdEUQ/B4Cm8VmTCGzIi+XWMLBUL1QjAj6

I8VfbK1l1I9JvKNUW0HC60L160WccsZzZJlCUyjU8MRc7LRr8Z9zq6aTM8X8Ugo85BL445p2OUbe

IEfy/jMzdBRIabOptmFHNHRH9VKiWTLB0jAJAoFI5EunjvDGDzM83BHHcaxE9bC1gfRIYcuTPjGV

RWlHanxH2XiUg7o/aBNAcnMpihzGdNm03qm4CnmWK+Goj9RJ35sX2oGwwJm3ihSuCTvElWo+w7Az

O6u1cQmhZMEvLMpIN1QVnKSgnbRKOHIQ3iKNoBSiXWyvoqybGUTK26iKwLMlL4rFTEq1sQPAjdSe

dbzKq4S42ckSCDTCkLuW48Kj5IJIpTTKy8FCXKnJG5lKqjTHuPRI2xG0B9Iu5xlE+mi9hnrCHpTK

sSwQbbw4tXnKPkJFF0QuajrMDTQmxQA2xJzFHRse/tVxzMeETOiTtgTRS+tZyaSsCqGkkzpMvhUC

JyjhwiQirc78mjAbQtMcQ9ScH+MwCI/Dx9bUKpfJDm9cjQToSzuzzXyExFXsR/l4l+QBI8lyFrZh

RuJ0Rtn5omVqx5i0RiHEsWWLSrEMiRSJSEosKizEHrr4Qbmbp/ZsIeFMS/GcLJCZuVvERf10mh9q

pMl4zs8Ii+msiuxEwNJTqOMAOJERJALNqJfzTz/0QGM8yAFlxfpRM3nCiAQljgW1s/iUzwctPeah

nmSUyOGolZjMUBjTJaYU0IPaP690nfYbCLw6muhULvg0pbXStE05LRetNSHEPvecUVlsl52DP6yp

/p829JjhuAkf7T5NgUgUrU46vMjK2ClD2VErE83twtAmnbFdKyfzZM3MdBodZZeJFAi+2yYTpc0G

HVKMilKo5E1MipXFgdHvPLwwRNP/FLdbColpZNLQiEywEp/PSjw02lK/zFMVFYs12x83Yr8jWtJQ

48NC/a70iKwYscuoWY70HLaKIFHksVOyjLYyjZfNnKQqK69QcknF/FBkJJ4kBFWMGiaGiynlbEXa

QNWlcIDNWFVWFZVJxVNYdUrc5Btgsk13u9WftFCms1bz69VmSSssupoo/cICfU32NIBk1Slc84zt

ZNZXdVZUecoqKc1azcDxI57ru1bi28FtfadT/uSlShNWm/QXgvQKAZmP5ayqRgNSBmXXeiLS2gPD

M61UolBTeiUt72Shn9RWfQ2a4wyob21T/wnY5jTWr4xO6LS0ZT1RSm1XQtFHRtwa4amMx4KjtktR

sbyx/tRYUpkywPg/RVXQxoDTngKbz+pHgw1CIJ06zKzZosEva6UVB03VOKLWyvRHOMqynC0aqLyk

f7Ug0IjB8nE4tjBaEEyN3EvZZl1Z4VNFq80w5ykiaJRZcmO3qtU6DcRae/G3zambjxXUCrQkBprV

HFsq9Pk46TzbhV3ajWlZJ2OadA1TB4ScqTW4s0zcwArPu0WrNYU4NkXI+7ggvKTCSTpWh1kU/pkC

Qp1Y18CTUfVw2EkKGfDrJvc7q1vdjNMVWYPEXMiCRtsLVr7dRBOhPxbNs4vq0gIT22o6XNUtQlWM

1piKGg3CsnVyPLhMH5zNXYzzP0HrD661VZQM2v96JD862TvyMMO9U8RdXcegqTJ0WqhFy1S9R3Sl

JQgKjPS93nbbuGDh3sJon+C9UuWzpfG9LsFF3eTN1bdpWo/CVKg9Oolaz3Wq2Ku7XzH8KcFaTYdd

or6rUmLjR58JqkVhCvhU2sqN1fUdttszxaFa0xnEKeCc4KGbu7o7w84lX3wjOB6x12qZUGIy27JU

Wfe1mARGpq3b0c3dCKpFzk594cuxPPjt/l0aLkxSuuGngFIkdbseLhAUvddRadkQc1MFOtQjiRIV

JOElztpDc2Ak2l+3rAkqrbqcgAr9LV54KRHpTN0D1kztYzJ0kTJxkwvUqpP8TFszRpW/yt5bnOOd

aMmdaFSSUtVwhK79C5cC9mG0jVimNWFYdB0xysoyvrgKBWJC3hhVmxfXutEFFIAqqAKzrMY2Ptbw

lcYI9MJTw+LL/GFPftaLnCfuSU39YlhdhZEWFeW1krX2jWUoVhJVZmWF7KxX1j8T1sNgwuIgpUwE

lNXAtdoIWrmLVdINhBhT/pkHEz9aHebDEy9j1jSIHRBlhhRrxBvcLdKio2XkrWRLxmV3/tXjKswd

x8LUJHsMcsHPMGrApUzLQMvY3DW74+RcpVHnwkhlVV7loDKIfylSI5zkurhjJY7Va56SxBLMLf7Q

XjG+xAJl/aDfJgYgg3S/MxumyXvh0XO4C94ITCFUuAgriF7locHeBz7mmARhSs5i6sRjTL5IdulO

5lEUAaZbCNNNniy/PeZGQHWsjqUQ6jBkfsXVbXUtDaSbgNsspLZemcPpsYboZbbhxbwaaJZn4qXn

elZeIhXiiPqL4ZVmMd7nA6zcyvFjV5sbvh4qdaSgbqtpxLzE3bLgDl20eNUOssZps8Y3Zy5lJcTg

NvppjE7e421YWb5rpM4UAvZsmw1P/vxUI35+JEQLMWJLqvbjKPqN6Sa1MYnxGq58uBNbjocmawFg

oxPpHjSJ6yscXJ8R4Vu2X/XV7PyFSwcdILS0qLxO40CkF9MOK9Q+Z5xAOhxqbeKs0bei7eVT68UM

a5+w7bIOZVBT06RG5oWqbOC+7KEGmsLqCs1jHnn9YniK4JGmOHF7ybD7JTNrsH3OyqEauwzd7WRq

XHDdbEzcivBu7PFu46iG0fNuox6Z5i1l7/Zm3n3pYPywoqwJTeYWaOs+1HSzblwNohWmIVND04Tm

rdj22WCW4WRWZtu+s0R+Cu9ez8XNRwmfx/XW6GZx76OWokumn1DjRAL95tgJSSpL/vIld+mayYk6

iTnp+m4NxW8OnWFrIU0EBwoZr42HnnEbPtbIJb3Jdh/lHgiR4HGQTiPTg9C/QiKQnbNlUfPGArex

dUktH8/VfnHOBZyzaOi7SOVFnsdVHuRkazBT6W7IIqADE4jzxe0KTxZ+/WtJJBP7yJqcLHQXLCQN

4jTq0tgOO6+SxFYUEfQuRzmK0W0A520I1zVw095SSfNMDxQMD7tK44tLty0G715y1pAp18TBQy7f

na30K/U84jfb1Lv6/BJWNxgbvFRMS1qh/u0z7knVnPZsCqZzkuRRH+bonRhR30af8XX0iaaN23Mc

L6sEQaGnfnIykoxY13XKGY/D/qpfuyHNq1vubadXUWYt2TYtWGbZe3PN/Irsnj6UCmpiva6hZ0cc

gkjeR+9x3U2+VErkEROMrYrmfSdkd2txoztu4fM0NunlZWf2JPeyDiZTF1N2T4kgFRP3loH3e5b3

vL325gShVMFImVfWF0uw4QwecGe7kRjuapZBtyLd9aVQEiTokOykau9XxlwM+1whLDFgzFabayq9

Y6NxTiodosPm9LP0t7OScQdBYV9K8Nn6sWplCXoVtX5b+lVgxBHMXnnJ/ibPTxpJqnd0sR1600rO

khdY53KyV8l4njfUldYVoI+il+z7iP80s8HIipZvtl8WLKL7A525Wo8hJFO3/qW4Y6u/evtM9K1w

EgkN5vr1CQ9Q/dVn/dY3fEgvpgHXFQOfV8hrfAI9Lrozbw+t+U6K+n4FW24Rfpq7aqGjorauM4iP

eMiS7FXBvMllenHKwjlniNa3/tV//eUHGq31efTp+DhEfacsjZMSEPL0CMlv23JS+VoffgqqytL/

LyUv36b5fNgvYTIHEUjq6NKOpcFvap4ACA8CBxIkaOMgwoQKFzI8mKAhxIgSJ1KsaNGAAAEGMGbc

mFHjwY0GLJKUmCABjZQnSzbk+BGkQ5YyZ1p82NABzoQbbWDs+XGkjZMpadiMuFJhT50ak/ZsuvRp

R54/eSLcKfNowqMCDnDN/sj1QMaiWWmSLTsTJVGZLpnCZOgS5EixUl8ClWu2IN6BZhfa3ev3b0uY

Hgc77WgVcEOhKvvOFClyLOLIFBnbcFCV42CNSxGiTTtZbtKqcJ8Snsrz8OOyJ1fbXW1j61evXYPy

pSz59uTFbiM2lTo4sGOYYp2Gti0zb97IxnEzrxia7c/CbW8rVokY8/Tlzf/2xWkZc+bfDodqhxxy

+vOoVE8DVc36vVysnG3CBltfQNDW2/fn9hzSN0RNgTcdUnTFpFR4B9LUXkjIFVQSg4nxNyFJ7REX

3oAjpcZdZ/Lt5VNoClIomYcIfSdYR+oFRd5VRUW4XkgvlgTfezMyRN9X/mDliF9f5Y1o1oZoHcWU

hhvONVWIBQZnAGi+mWabYzIagICFVDo4kJEBUvkjl0CSduFoHhlmlYwVdUaUjxdpJl6XuFGGmZOb

jWfdWWlORCNrgPWIY1f35cdXm7itxRmdvvlkmqFkEqiTaBEKKB6UCEgqKVBkUlnppQRtpOmkFlpI

1ZQaJmZnoM1VGh1phi61VpJmdkiqc2uGCGupRgUYZnYsulcTniUy1+NB99UHFm2A1vpXYXWl9Bhx

q7aVZKtIienoS09KtNGlIVHKE5VbhmqlB1OCG+6l3m77Lbbp3ngsuzqRmeiac5UmapYKVecrsgZy

1q5fjD03q65m9Upj/rt7viZsbCLuy++CglUqEqoJhthqtOcZBmOMAi7M25aXldsttiCHagCn6p72

cbmh3kgrw/uJmSpb8yJ6mQFD+SeoY/a2vKtbqxZHHss7swTsa7EJW6yxQqtJbXQgggjgeS+WmTHE

UhO4nMraUjpyylyPS+623G6drbhlBq20ZBnGrOqhbB65Eb6AvcXg2UK/qa9icaOt58pFG50w0lnV

XSu00qUoMXpq6aukeRxjmi7XkFtZNpbZciv54x0Lvje/c68nIGmaLQ76opE92tbgO7+ZWt6pc27S

un7bB3jg873O27OyOhszXF4uSbPGtbfUceTFpxxuqJVXibm2Jm98/jvh9Q6qdnE9EVXxdc82Dr2Z

n+nGvZt9Iww4Y653CSd20xrW+9Q2PoxitVFpl7XY357bKdgkK68TpSA3f7ntwMeuEqUmZr85SU8Q

CJfDmM5n2xOgUYxzLwiGz1jjI5bCngdB7ISJMP9RTowQFaXH+MhR9ELNpgSSQk15QFqgYtQHM0jB

NunNQlNBSwJVpSK5iU5F5muZBAM2Q8QY7IL40SASwedBACWgZjcTnN5M0sQxle6BfrkSXlQzRH65

5lpww6FGVnKh2zyKblskS4fOSKJ1DUs2GPxT7IboKEJ5Bj6bu8ppomar22DxQWhUY8HyBJHqnM5t

DcyZFQEZtzQC/pKI4vvbbAKYtEbSEU13IpVNIFZFGS6EgRXpo0HqREmGddFeNnuI57D3ofi154dc

pAwjR9kvYLWRdpyM4hCFVBP3RWeP19ohRUAZSpLgUpZdEsu9XFTATX4oSok8o21iacy9FDE2RtNZ

34ypy+4RE5XOjGNL2EYSYerFVa6c5iwd8ipJVsVU62ulLPUmTXTyTGdGnOQzoVmoO/FycUlEUJjG

Sc4WSvEh56QnNavzxIPiblD/nKEEhcRQSu6plpG8Iz4buc3J8PJ3D23U7gRKzgjmE6EUohHQ7DVR

4KSKkxCMYutM2i8J3WdHtZFQPIUIu12mpy7zgwowJTJQgqpU/j8yDdSZbGZJbI7IaahTZES/d1SB

rcyib3zmSo+5z526CnRxSdPcPClUYfZqkFmdam2UekqiNbWHZoTmJaWK1j+y0Zp9AidTNbpVrnJ0

LU1UC7OYqRAH2VF4vpzrdpLZuhKd1V2gYmBjf6WdeSL2LHXtky2xmtMnHpaf7DEkS3oTTIEUNqOd

rSyJTqlO3cgnshYbYUk5V0zKonZoibHqEfGKUTVulKPdm+LMABtcdRLMt9ysrXLWOSebMPejadMk

olwLwv5wFrm2BdQ9cZpN3ur0tGadYr0qBB4mFTe25nWudYem3AkirbkTYhUiXbq3Yh6ku+m1EXZ3

lNm8qlSv/tUdVU3+1b5byWm2xDzwfamp2tXusygGberLgipAO+01wfi1p10vqlt25rLCg+QpUAfc

s4eJWL4b1q6FW5TSOW0VK6Wk0DchSqr/pvi4Y8nuhwHMXRqbVkLwbcxphnviHBu3xt1c8YrkKkn6

8rDEsoUVk42c0YdY9apDjrLSeuvZS35WlUZxqojt5CMs1/hMDn4VngInXXmJFXosWzM9KwpJKw/Z

sOCjLYph5zn1gpnLu/yzlKWIZPaOCplt9WegE63O/GaYzjfN80s9DOnEFLKbChwjX7dcZEWrdNAL

3vKaY8xpTusnATj+LpEpqOVMf9iGTnYxm+Hk3VRretQs/vZPMnmFXh621NaJljNm7wo7WBKOJlqO

L38BrMkStzZjQk72rCetaOXmB8mu2vUqHerradfGjd7mKCzhrMezFGrPb70Tq/KoY52xSrBpErdJ

c31rWp3ZZbpz8rZR2xoqzzm3wy6fuAVMtYGzp9y7S9Jkuyzr3bJbTmFGcL69Vyh5W9bEfulzxKVc

6ir726xwfHRbNYSqka+vI56ZmLbL401Ef5zSgoU2rTO+soBR3NjYbgwHXy5zfd/01L4kdsjBNC+h

p4Vi2SnPeI/e105O7d07NyvNP03VlvN6TPh+Olr3LTsd7Ve74XZZ1Hx27wtVrejaa1UJBXNehU1L

2jF//rqZGbzUdNrZd17Genrjw6fZaZir+CIzhHBVLaEf6idmP5UhwVpncHJQRmLGe37WS20OWVxx

oIV8guNDmws62usAZ45XnTX20JUdlVRM/IXV3c2oFWlRj8f6alYcd+rcfGl3xzzP++ttPwGa6rUP

LZLoQnigmtz0wc9OaJdtW2i5PvURX8k6a77Gujdm8G3GPXL1Hqx+d5yvf2fohhBZqQ+SeCN0iq8n

wTo3nY8YQSDftK+hH/3J077y4o3w1bGPUO1v/dsQX/T72Y2kLZ5SwAz7MU6jEODa3dnANKADyp+u

zN5+OBgZhZf+6RsyaUW/qVd/deCIPCBr2NfbtYTI/jHJ7QHHTlSM071UA36GINWEaklfcxjaBdYg

XmngBnIgw1HfsaxatN2KCR5gJ43ci6zgk70g5ZlJSsngDO6gDV5gaxWFz+maBwKg6gxgj+GO6OSf

tGjbAsJbQb2YZAkaa0ndhGjeE6ahmknhnHXeZ7wf4E0gFvLXgKUPk5BFuxXh/9UKEv7I9y2htZ1U

Fqoh3rmYVkyh81lhHM7gHAJP1QChqNjfiI3fIFbiSYFhFVabdTAhfxgMIULhvrBhsPWdDkLR7+FM

XCxLgBQgXWxSE8UY4HkZlmGi7/Ugc8Ugnp3hun0i5h3Fg21fDtbTkmGiX9FAxUyM2GGPAi1OLLJa

/q19IC2SoSURGg2RFC/2IjtxXve1SDYtot0lC83IC+slyLoUklX8EJmJmzd24vyJ4Af62TXC3XyI

on3wXkL1zTo2TAkaI/z02lscTuwQyRZKIvwV5AxGY1zRiQS+jhjG47ZRoFgY0TYam8HAmVeBF7yw

SRk1H+sJnxNeF0hOIELeyVol2dzxIRU6ZL5BZEIIiz3SXW3kI/D9BEoYTgkmIE62HHw53tm82RmO

pEksIf2VipgBpUrOV3NF5I68ZBLG5I9UTU0u0LzkJNQQ0PV9pEHamJsYJdR9z1AilSgd5aglpUJo

I4l83XuRRlQSBjhCTTvx4LUlolzqCVd2ZR19/iVYUqRYcpsVAuMoTuQ9btd2DMpavk2M6ITemU8f

CmbFUUddJsaCUWPBuMdj7iVRhmJZtiFgBqYlIss5qmLG2EqNnNNi1iIenSX3rJcZTmZCVaZl+iFm

tqTRMGVy7WInzmF5EWSL1Ah3oObtyBte8qFiyiRJxI9xHidybuZrHtcvyuYoumFTYiV1TFyaPaOb

EZFrppVCBidKnqUrHWeOdAUA3Md4xkZ5hudSJmdyLmd7CY+f0OYlvV4mMuJiBE12elxvpmZkcmd3

bmXcqGf8oKeACgAAFOhHFOh4ZgSCDouANqiDzmb8oBZsJVZsOudfKidxnRl9+Ypr+eBcvpeo/jlj

WLqZ7OXiAEkGgAbog65ogxIogr4ojJ4ni84ojVbWP7JP/fUlQrxn181jQb0hzKUWj2nloRlIJDLm

iP6maioZEAUNctIolEJp/MQolSZnlEbpNLWPOcaLIyVSG8FnQ4ahNS4gGjWidS4ICYZfMj5NACYp

Q8YSf/ZgcRrnldapgx5nWSaoghqoi44nRKTokzooIC0Tiblf2Alh79WdS9JOmM7IIvHfr5jpTklJ

DDVUaP4j4oFU6eQjcZ7Ufgai6vwpndopjQLqS1AEgfapga6qgUbGesIYsgHZy4hciOUkm07XQy3q

bDQqRZbPfBKRpDpWSJgetbhNAQVZiGXI/rg5SREOTqeeYYm6IxcFy6iSap+Y6mZia7Ww6oJyq7am

aLtgqhcVUApu4dCF1LgRx/R9lDYyVJhCqpCSCvoEFIIwxduAyJc8DTIi3qw4631q51It5M6oqLXW

Y7WwhJXaqYseKKv2KYMW7LXiKX+MF5GMX4QlKxVFReGpiEBe3tTpaGbOBnzWJn89qykNKQreG3uw

jdO0DbO+7L4G2QGljsmKZNQxaa0QrMIaZ0kkLMTuCIwurLf+LJZObOLkoay0rO4Y4KPUq8Yi6ne9

WHMuxJfaFBrxal8y1nSi7CSO3js5VSsiXgf5I1SUIM3+K198Ks5ySbWQqsRWRKASLYuq/up4NuyL

PqzcCmhaMghbmiuulCDYAi7ZXkylumBuAopt8CgpmhMUoaXvkWawAlSzVA3G5owBfcngFhgXjqBs

RWvk+kXclirPwi145u237qme3i3dnq7PNujeglQJBpS+Yi7teuHKxufhXlviLqXV8kq4Ad3jKsfn

hl3bzWrZYu5vDIjaYcztdmrN2qxXmihNpKjbRqhEtO7PIqdM0C2VBi1gqGdaosjlTsvwFQn5FUmY

lRXf8KDiQuevImkAeWK/DC+zKu+55txNqttVFtXZqhqcgqpFqGfeGmy2lq7cvirodq8CY+gGvRPL

joZ6yFr+DYwuUp+p8W6PSqfb/Yn8/goM/YojmCBv0xZuGGItN0ZaBMbpwVTrAEdsRpRl6Gav9u4H

9y4wOmnbvAKusEZtaeUlh+4dfozsKTrX1HKYsX3wxASF2pCfOeUuXUKU557kCutsC88w9kLsDAdK

DXcvA89QlqDGsvJvDwPRAynltfZuZ/5g5G0wDHLtKrIbJZZwaSYW2gKsL6JFDMsw67oR0SLwwN7t

gjpsipGXEzNk43jIt40sp/6oAgalG1taTBayH9axdl6xte7xR7QwAR8sBJ1qqlJrF48SBYuyeTBG

+9IZcUYUfpLbIwOpJJ8o+ORxwWqvJZvu26JTKEOT+soUGlJGG8lO97lOwtkmMX1w/pu+qdLUcvWO

rgFr8iaf6vOOJV1Wp3X1ckS07wsPsRqbJsj2h7+yILvI8izfMgvbchYf8zVi0i5rHPxaKLG8JDq6

4Cq3cd1E80GOiDIvs/W2JBXr8zkn6lEm5ihnXAc3BDYfkckmnDy9mzHDpepMlDhfMnIGTDPXqR/D

pGXmpj1nHRv7ZT2SD67+3JiSZCvzVurks0VP9NzhcT9f6ejSMXveEiXPVztTbcIcjSupHBErYUlv

kfwN9BS39Dgzs7YONSfDZkzL0EbPFWPRl0v6SU7b2EKT9Ez3KiKjdEq/bUUP8EsTZVXv3/vuHIc6

tF8GsdFENfxN9SA1dJa9B1bv/mxXB3UmO7MLZzMp/evm+rQ2/5rWkjUwH0xsoDU8ltTfsTVSsYYA

a/JFyzUfK3ZcmzBSc84JUpRujmVf218iB3ZIiyhMeYiHvtJJJLZj3zI/C7VLY2tKejX0jDAv+7Wt

NWSzwe1NC7HNEakGr3GSRSNivzVckzYMm3aUHudKqzAxXyL33GheT5hrk9pYr90v30c823aQFpVh

N7FoV/Fi/zZwS2lXS95qnjA0CtCEtvZX281l194p53JWEuCGVvc8mlpEY3F2l/ZW+/NHRFAUO2+H

lnf6ZF15NylbobdN0fZpSjc6Z0V98mYE7fZ22/dRGzRvc/c+u8rNrq1ewjQF/uFrcv8kCB7uUh/V

uzbyjt40Gr9jaqctZw1MfPf2hDPEdXN1XKvYdgIwNWF4A5OjeQvjf18LO/5dR7uzWS9uYxo4qqG4

KZezUce4dje4RPu2gqUwjXMmycrRmkAtO/qmEoXoZF9t3flqcZJ4Bu/hejMyYzP53P4z1Ub4aaN5

pLKWwK4rdqqRuDZpBQmNlLCSs234GwJvGo/4XRE4kIr5nL4Edrf4kpt5Vjs5l7SjhXdpdMpRl4Xq

r4CoBfLtopwO8em5NUbTNvMzmAt5XH6oi7dtHzv5i8O4ogcSIEb5ZnP5oFp5WTBQ+5zVWc25oSaK

q1WNVzkmN8uXnfAeoHe6/m6peYvG9ambc6ojJYtw4qQLzI4PoaYHXjL+uJSnjdVJJa7POXKvTZz3

Og9G2XOXOEBf87FLuBUTe3DPdy6lEbOP4YVTUhlF+0Qgt4jXOOgdLckdjkaKHrfD5DALu59jULDP

Z7k7OPXSNfhOVfSV5DG9eyNtrA/NO87FamV/rLXzbehRbv5CjdC1JnPptIj+6YCHeVYUvB6veKmz

eWWhWfRVYymOUryfG3DAEG8Uar3n58XDLszGS8zqEJeql9SC/JmKvMjaksmnPIA6c8LzNdAAp5s9

+y/NuhZOO4HNap+3+sVFMM9vvbIua6FOcGkaYcgb9MhHLF0/s6kesLqn/qn0KDy7Sx28vRvUS7wa

b2wdHm+EYOJBKWuz0C6BbDg1Hzi1kwrnqT3ryrdxvkW+DN6tx1kMBqI6qtzc23uAoO/d3yTCCae1

c+zTRvD+8rCCBzqRDyKSs3jaF7rhXU8m/T0JV8i0P2KcsTyoquPow/vYs9nLrc2sBJLpeBIK4RtQ

u2ntNw6ioyf4onyS88hqWE+/d6SU/L6S6DrLURSje3lkzzNCxXw+idbtza7MCycttmBy+SS51/eZ

zyYolz7SS6yCM78DB1byKkrno4f1oas2/S+aBHgFj7RM3ehTASFA2BBow4AAAwMRJix4sKBBhAkS

RpQ4kWJFigkwWtS4/hFjR48ZN4a02FFkQgEnUaZUeYBlS5cvYbJE2XKmzJoxceakqZKnABsgE3qc

2HChwYUNjSY1gHSp0aNKBx4l6nBhSatXsVZMQIMrDYg/t3KF+DVoVrM/NQI9u5bt1aVv3z6sWDWq

Q40HBS6V25ZvUJJnP37si1VoyJ4CdCZOzNPGyZ2KIds8vPeh2oF/5xpUqvkt56Kd6TZNiZeg3c+l

SQ9WfRVjV5CtxV4mK9Dy6rJaZ9vWzVYqXMoS6ea1m1sk8d2AC0cMnPx4ccwTD0eW7vIwz+k5q3P0

O/F55qdSUX4XzTlvb4ShlQZvvl62669hY5O1bFw3fdr22eenOH70/uXMToPDTyv9+lpOQAIlYg6h

nq6LrLqVGoTpQcBku+jA8zw7SbSmOGSqqPSgEg6vpzS0C8H6uvLqPvf8q7DF42pz8cQZgQPQtxeH

QspEtPaL6zYagVxPsIGii3CnB4s08iXHbKoPLAtZIwo18DrUsEoNS8PyvC0J0iu1INuC7zUxcytT

PhiN6w5MGj/sD8ce9fpNITffXNNOs4RK0kgkq1NSwpt8Qkym+mK8L6sE0GNIpe8W9bHLL1Uz8E7Y

vHovRfrMfM+2GAu980S4bqyzOO84lNPTU0dKgEE/D+CTSVaXzE4gQW2iLtJOO+WIBgPIIg1UgvJ6

NM7BDAxMIg88/liT0oyWxa+2IcNM80JU1/PQ0Qshpc27YEWlFlU9I3QV1pgm24jWQGkqcCxMp70o

tvyKhfYqZJEFEj4VwWIxVQvbVa47Bb0FsjM3DzxKOVKH5THgE12ldU8+x/2TMX/NPTLdtTDDNMx3

MY5XzX4topfeGcmk7dKScM3Vr+fkXdhO87S9y0pT61q0W5f5AndcJCNu2KoLz3XYp0PV0nhjfPn1

+NC+RBb5rqF+LrlZwuzz2FjZ1MQZz77Ui/kuovDCD9TUQCZwaCJNMmzViCVbG9Zyb47aonMbu1ju

7Q7mK6zZloPRIkcratrp/RCA1IDCnXNtRbHKxjrrkADWWu/G/qNSFNKC+XNIQKZotlMAAM7+PHTQ

F9T5bdMf7glydSl61XWUC02TWI5PFBuB20f0FVhkl6K3d96BrRzxLvMaPmHlTv4peeesbv5qydHM

CmynOq8ZQM0RNpHy5j4HAPSTvP++e/EdVrLh8s0/LPK0boXuMbtxqzrB7ROkHUH7DvfxcMTzL9yD

/Q3wP9wJMH/Fwx1BDlhAAM6PRVNz3uOgJzmV9YgnpMGcr7A3FNNoz1vjC98HP4g+6ZxPhNeRVfwm

GDc8EUdodMPNSLgTKfsRiD4FVEj+9lc4HBIQh7jT4Q9zB8QefsmBZEphBJE4IOn9SoVdO8jmnMJB

z/EEhFX0/l4JY3U+VsENORBU4QpN8r5WQemFMezRz2aonxoOLyq3E6IA/TdEOQIRgbjroRvJJiaT

uYd+SfTjEUf1H8BBkWAz0pnoUBI+8F0xixDbIhd307IvdhEjLbzY88iYIEGiLI1qBA4bEbgUOvLO

jkI0pShROcdBnmxqftxI01yJtzDJjE6bY6LC2HOTxYAOhN0bH892NjFl/UuNQaMJIA11kf0Y5YEe

6eRgsoXL8+iQIae0Ae9UqcpSplKIYZNayWIZMsHVK5yAHBvZNnJLac4pPNWzzXR82csrKhKL4RKm

y/7SR6sYc1B3M6MGGRIqrTyTL13zWkRyWM3CLTSAcGwo/gB5GEeG1rF/Ci2cA5cXToqMc5yxxFZP

LEjLUh0UoVEMqX4Uo5IrLpKXLQVd6u7pyvXZhp/9XB0Ml6kZOrkLaVyLi5R+BBwvEY8h18SmyH73

P975TqnlAZavlnIvSzFOo+LkKEf/iDmTNlGnOxIbVaSYnyP1yYMtjScjsXPCqvIrPzU9275wepHx

AI6n+mSnlbTUOf2BciBX9StWCWcAqrZyrcf6618jqLJEcfU73QLNSNd5HOtgR55mDaFaC8saZGbF

rWmZloAQBVTIEdQtVsrdjiKb0FA69ZoP9d3vAtjQ/8nWtU89T/4qlS/SVvWwvSUnzhS7VZKWtLGR

zVIF/ifZlxHS04MsvWJmV8Msu7ZOjG9dmXP+ViLUDrSnvKHKT/OaWmsucIhwBKJEJcpNGyaUWRmF

rmF9i1jg/qedw50T5+w7JXVONyTLteJ/SfdeYjmOv7MS4xgrU7aCbSaayOvuWqbSTqAWS5UYUW82

8YhhUTJ0iHvMrYA1Et/eLswyUB3k105cIx1pqcAbkVhPAPxf64IYY5UBiyRL4joXPmlp2eXQdrmz

W6uArVR6eZxqFZjhU8oxohde8kXBSeMQi/iw3gJKb+hKSPXgT1jDarFGYmqSGPdSygO28cpmKhG3

epF9Ig3vSIQ85NNa0HZx0rCGSelkPecvymV+JZWr/uypK4OUseSJm0GN67kxh9DPBcobCq3m1hmz

hiOg4eSD3ZIaEnnzLmxUpUMJuM08D3GbpC6c4hptFUCPeFKVG1uhIftVgX55MM2lpyJT7WhZrsWS

Nu1xm21bnDhrcEdgS+bfPM0/H274oRz2HymfXdEhIoqhw851QlYdaDDNhkr5rUtxE73isAYsJY0J

MEquretdm6WzFKo0XIwyWkynE9zE8zZwFFI5RBEQqflTar+RqlREcYVXednVh9OdlWxrm2QW7upJ

hcofdMIpVLSWbMKdpEleH3jSN03nYRr8EGtbz3IUczSooS3b3hZRX+nE+EQWLt8ZMYpXmDzufmVm

/ulEvzzh7DqLjuH3s+KAytBwnjcFydM1ZIY8ZrNtWlJX/k1UhwTRPI85w/PzGSAHZmD13TlqvG5x

nicxdtuTNNVGRfTjBfnoKgZrye+t4gaT5erIWtbi2l6jeI8dIXXHum5A43VBHuVMy/xx2PieeBk9

ep/U2THKUCbuN9cv71EB+9uD93ViR3M2Vwdnnz+u06LSSOwl8TurbcMUwRt+RJqT1H0NXXrFJ9Zo

V2m30NMO76qLvPKoATvceSySrnO+7wv/fMuF/92i389Oflf5VQEPIqaLCENz98iPWTx77Zfd9tSx

FeQhv6HRG11slm4snYccHtHWadUsp2r68bp8/mVG6k5XX8jfCyr9j2sayMTt0Ou1706mj/7mp/tq

xde0I/K0awD3CH/U7+28qrTGZu/Yj8ruTrd6T+7Co//OrMwATe3wz7ssZ/eqrwR9TDj6r1gCEEFI

cFOkpfEOEME8bugYTN6MQ/wyJEDKhsjiD+KwLb6kysMykLhEpCqsL+OaT8R0hChC8CymB7IGDwo3

79uipm9WcDUM5n5kRySADgGVSAEPT9i66zQ2LfM269s2MMUiAgj1BfRKggeNcOsiCVXiqzf+xyCa

0AnFjQElbv/uK1qs8AolMAvVaAsNo7pmkAZF79K4bQH1K6hK63ryKHD+yv0QbolGA/MmDgnr/s+3

7g+p8NCvduPV3pCutoX60CQQ447vpmfyhIQ42kVovi+uwk8K04J24hD4js0s9Ed7BKQS9QgD+Uv3

fK83xE72zKK3PhGbQlHmNIrIWjCSCk8Qp8S01q45noULERHYalGg0kKwIAK8So6IuCZEgo8Sx+kC

L1A1cvHyTIMBIQcZz2KpxmkZP+T5oK+qVgwe/YYas6TIVo895gNovM8LNe5n9jD5eMVDMK8DseJ4

RKtdOOr43i/1itEzNo0fMylgOMTpfKcZpYLK9NEb7cUfq3EECRFezKRiZGIW/0no1E4hM5IqHPIh

38zLVE1kWskNsVC7RE/0opEbUcVykqIZ/u8QNGLOJH+NGkdwg1JSIPnmQG7vJcPPHM/oJJ8wwR7y

2xDtDHVS6iqyOTYkioCSAxPxVMRjAUFRQ+pOKXHPLZ/KKQMSG8tkbs5lJ74QIWswpywntB4Oax7S

YLSOiCjH7oJxHfVDPDokKDfSWwbm/pYRm/Bx4eAyASuzCDGSJgvRneomBjtuFbmD5rLLIBBF+mqO

zVivByNye9wI1YJQXWzO8v4xFwFn+s7wU2juKE9PFC+TO+TxvbKy3gTSnWTRIJNLOT4jGqtkrsqx

P8CNfhAAB6QTAV4D+ahmfSQptGizvkjwNhPz935PN3czH3uTM03S/N7uGqUx7u4y6MxT/q5KBB6Z

QjvZsSiZEzQpIjqlEweoUxjp5zbziQqTsx0LUEjkbByx5DQIYjydsTx/k8a2U/w2c+em8j2ViSRH

s+DaQtOW80a80wZuZz+n0z/drYu2ROtykEvOcQ7f8AGJ8j5Nry3LEz/P8yKzUiW9zXXck0YTREJL

cQhPUfU2ZPGsIkT383aEscYAEfYeE8tI8zdvEKGaMumSTj2nTEZnNEuJcCqgEV4odBshEf6GVAzt

ajsxkkhLQj+P1I0QYOqWUknVAiWvRP768Q9rBiDnVCM3Cku1tE+Dh+bw6xXto0J5lAh9j0w3VBOX

DzpFlD+NlD8/tFDzckWlZEDzykpn/qmknJIMi5J6ajJGr85PRdXynnAx9bQK3YcmXFJSq0/nbNAJ

qY820VQkHnU6a7U/Ba1AnUpBg8PYogug0hMHAcTk5tHvRnVUi6tNThV2qMszGS9KdkpXgNROZxL9

suJW3ahREeBUUoZJD/UfXVFJ/a9TfXLyUBNUk/JY/RTu4DDfCDAiCPU/p4Q1Rg5DtmpMVzRN1dRR

99VRH9QyN7IpMSigzJLSgNUasUwHdcNY1dVBG3FMjdBV1W1BHC/o/lOdXpUXbxQnzaJfs1VEkVTz

PIkjGvFSrbFg31JTN2P1OO04GLZhLzNO4xMzZ7Z94BVMWdV6wrWueCNQjzMiapVf/rU1TEnGnyCr

TcJrWe9NMG1EV83sB9MVZmO2VwQWPIpNb9QMZ0VWrogRURPVq1jTY4N2W5+1aDVLNmdTMCU2ZQ01

86iSWOgjVKW2N0sMr1qP/5Q2TIPm8S62azN2QyfxWvf1Y9d0/kqSaB42VtNwawwvkDhxDSlzbumW

2xCU/ygQOW7WWX9WZeeSZ12wY7V1bMnWcGunY7iNK8lyWQvGcVkU5iJXcqd2XDFoEfN2naaybzGU

u2iNUUF2bPflXy0USmqDV1GWdNkCGX8x22DXYUu22JSPMY23pmRQXgGjXoVSX0M3dOFqa5+WcXeR

U5W2wKAUHVdteZm3ckwEGunU/mBn5faoF0+stzGxd03FdnvzFRuPl1gF1nsz9RX3VHnN93y5RUQy

sXZJyn1L9FT3hnWuNXQ99nrvt3XfVCtvjn/710BdF4ADWIDvNCYvGIG3xlQZcIGjBXR794FpkWgf

lzA8q0uK921LFCozWIM3eHJ7xXkNGEd6DcEuNv52lvfsKmyzt3ft9yDxN4b3JXylB4brFGppuIZt

eIBREWuJZBt7eH9vcVqNuEgHV3SLmInfdYK/+CypLn1zFnMh93WheEaH94Wxy8A090NLE4vJT1yv

AltReFJTeFOQmHku5FwBKlbN1omfeI1jtm3VrTj7aXvmmEDr2ILTdIgLd48h/nhiWbjHnMcJ0zc9

mC+N1diQDxmhkLDdGJlLGZOEL/mOxVZ7y8iffhWSWVcsN2gvvdSTCxmU3fJfyYKUQzg0vNaV53dN

h3aM43GFwS+Vq2VTZ4Z9mbmv+BSXc7mTz46RZZMfUdmzPhSPh7mVxfiCgfmYk/lueRUeqdmWbxma

qRF4dxkRqdmDpRUWAdCEhZmIiZltqRiZ7fk44rAG18948/ll0VkpgZdHOquUCU1aKyXNOnaV6XlA

InVzATafyXgUFzAti2zu+tio5DagBbp2IELSDNpv37k5RHeb8zKIw3hkE5Npz88+pfR9CfmcOXr7

zHbNQlhF/9Y2xLaLI/qh/s94i4dz5ux1pJZzqDFVjwUCoGf6CgeaoKvrDJvJatx0MBh6kik5iPlr

oJvaLxRTEqtPwiRaqXnunMi6rM36rNE6rdV6rdm6rd36reE6ruV6rumarEG0qke0hcEYnO24loPk

K1qvXDfZpKCXfKN27Oo6sRV7sRm7sR37sSE7sUsaZEmWkpsZlqPnr4lD945WEgs7bsUa4yJ7tEm7

tE37tFF7sR24obnZn/G5myWYLlUwp5x3Udw40U5P8SRuAodvrnybs8UPrUfjrW2krou7rYdb7X5b

/azlsRL2nI6bt5+brCvorKO7rK8buMm6d1m5ntcNtmMZg6VRZY6MqBH2/rP/95lFu4B726Tc27mD

+7yhu0mRu7GzW7jTsL0Db79F2G4T+77NGsBFWLjrep6PtJjD+7UVPLYnB6oLZWATd6KTOrf5zrQw

skMtlUrgjcGG20U5G0R8+OHa28KrW7k7HGGv570/nL8zXPcyJL9RNMSFlLmTG7hpXMaX0FpEPMdF

fDSElrIjWsL5esH5OLr0CYLUA73TW73TDcVNnMUzU+04w7MZbMUz/GRtnLBN88lbHLpt5MsXM8oJ

e7/B/B4tnMvPXDGt/Mo7NMrhUMvd2ym8OMgTXKKHnME75lZuMML1esk3+uVctMx5/AGZ+/Cm3MMv

3KIbpVRNVcsx3MoT7p267VbQTxzHHwvHX/zSEd3Rn5tcE9003fzM4Ty5NaR+6fzO7VzIUxqNCaUu

qbDP/fyw1xvGLx3KNTzw7LPNl1P6VHxArbbW1RzY3VzS45PL2by/x7LWc73Fl33L11zMdR3Obf3N

O8OkLZtZ+/qbjflsVXIsRNm7nXk8ETvHlVvHSby4eZ3QU1zdO3XESaTdox3NfTs9Nly+yfLee9vG

d5tKKt0+d5zesxzfLfrdcf3eVxbfrfp38zfbU717r7PhQCaFGPS3RDu1A/ziLX661VrAMx67O96+

1dpWEdynjzyji5xohgm0jmjiKT7hAgIAOw=

------_=_NextPart_000_01BFB99E.F58E4670--

 

------------------------------

 

End of WFMC_TC Digest - 25 Apr 2000 to 9 May 2000 (#2000-3)

***********************************************************

There are 2 messages totalling 290 lines in this issue.

Topics of the day:

1.   Comments to the Wf-XML version 1.0 candidate (2)

 

----------------------------------------------------------------------

 

Date:          Tue, 2 May 2000 14:04:25 +0100

From:         Hollingsworth David <David.Hollingsworth@ICL.COM>

Subject:      Re: Comments to the Wf-XML version 1.0 candidate

 

Michael. Try the following for 3.3.8 Para 1?

“Typically a process is associated with some number of data items specific to that process. These data items may represent the properties of the Process Instance (Workflow Control or Workflow Relevant data), and/or any application related data associated with invoked applications during process enactment (Application data). (These terms are defined within the WfMC Glossary [9].)  This collection .....”

I don’t want to start another debate so if anyone objects to the above, please revert to the “target” phrase !!

Thanks to both commentors and editor; I feel we are very nearly there.

Rgds, Dave H

-----Original Message-----

From:         Michael Rossi [mailto:mrossi@CRUSHER.JCALS.CSC.COM]

Sent:          01 May 2000 22:02

To:              WORKGROUP4@FTPLIST.AIIM.ORG

Subject:      Re: Comments to the Wf-XML version 1.0 candidate

 

 

Hello All,

I’ve made some changes based on input received thus far and am just about ready to send the spec off for publication. But I do have a couple of remaining questions embedded below.

In addition to the changes noted below I have made the follwoing changes for the 1.0 version:

*   added headers in the examples (I found the keys to be helpful in a walk-through with a newbie)

*   added the definition of the ISOLangs entity (used in the ResponseLang attribute)

*   added two new examples in the header section (2.3.6), for consistency

*   changed “EMPLTY” to “EMPTY” in the Process Status section

*   regenerated the TOC

*   did a spell check

 

You can retrieve the current version (with these changes) from:

http://199.210.109.10/download/Files/pccv3/Wf-XML-1.0.doc

Please see below for more information and provide any further input ASAP.

Thanks.

Weber, Rainer wrote:

>

> My other remarks refer to just a few (hopefully) obvious

> bugs/inconsistencies/...:

>

> 1. P.2: “First printing January 2000”: This should be adjusted for the

final

> version.

 

Changed to “May 2000”.

> 2. P. 5: The change history should be removed for the final version.

 

Done.

> 3. P. 7: The wording of sections 2.3 and 2.4 need to be updated for the

> final version.

 

Done.

> 4. P. 11 (namespace): It should be noted that when using a prefix (such as

> the prefix “wf” in the example), this cannot be validated against a DTD

any

> more.

>     (At least some preprocessor would have to delete that “wf”.)

 

Added wording to that effect.

> 5. P. 12, section 3.3.4, 1st paragraph: “ncessary” -> “necessary”

 

Fixed.

> 6. P. 12, section 3.3.4, 1st paragraph, last sentence: “..., and in the

> interoperability contract for the particular implementation using the

> transport”. I think we should drop that phrase. It seems to indicate that

> interoperability-contract-specific entities should be introduced there.

> We should not widely encourage that other than permitting

> this in general in section 6. To me, this does not seem necessary, at

> least not for HTTP, and I would hope also for the other upcoming

> transport bindings.

 

I agree, phrase dropped.

> 7. P. 13, section 3.3.6, 1st paragraph: “pre-porcessing” ->

“pre-processing”.

Fixed.

> 8. P. 14, parameter “Key”: “... only requiring relative URI ...”: We

should

> indicate relative to “what”, i.e., where the base URI appears. We should

> refer to the transport binding section for that purpose. By only reading

> that sentence, it does not become clear.

 

I may not be clear on how you intended to implement this, Rainer. I had assumed that the base URI would have to be managed (created, stored, retrieved) outside of the message contents to be useful as an abstraction from the transport layer. Thus the current wording:

“It should be noted that this is not required to be an absolute URI. An implementation may wish to maintain base URIs internally, thereby only requiring a relative URI within the message header. In these cases, semantics and mechanisms for processing these relative URIs should be agreed upon in the interoperability contract.”

But I now think you envision it within the transport section of the message. Please elaborate on proposed usage of relative keys and I’ll adjust the wording in the spec accordingly.

> 9. P. 14, section 3.3.7, 1st paragraph, last sentence: “Naming the

operation

> elements in this way .... exchanged in a batch ...”: We should not use

> that for a reason. Firstly, we do not support batch in that version, this

might

> irritate the reader. Secondly, the reason to me is that thus we can

specifiy the

> <OperationName.Request> and the <OperationName.Response> independently and

also validate

> against that specification.

 

Right. I had to step back a bit to rethink this one. But I’ve got it now.

The 1.0 wording should be better.

> 10. P. 14, section 3.3.8, 1st paragraph:  “the subject matter”: Could this

> not easily be confused with the “Subject” of a process instance

> (which also exists, see CreateProcessInstance)? I would use a different

term.

I’ve changed this to “target” for now (for lack of a better word). I think “subject matter” was closer to the point, but I agree that it was potentially conflicting. Other suggestions welcome.

> 11. P .14, section 3.3.8, 1st paragraph: Strictly speaking, also the

> ResultData can be part of the Application data (and maybe also the

Workflow

> Control and the Workflow Relevant data), i.e., application data that are

passed back to the

> caller.

 

Adjusted to reflect ResultData more strongly.

> 12. P. 15, last paragraph: “... the interoperating parties should agree

upon

> ...”: I think this does not only depend on the interoperating parties,

> but also on the specific process definitions. Each one will could have its

own DTD.

I’ve added this:

“If this context and result data varies for each given process definition, separate DTDs may be required for each defined process in order to support full validation.”

I thought of discussing namespace-aware parsers as an alternative, but namespaces aren’t “officially” supposed to be used to reference a DTD for validation. They’re just identifiers used for differentiation of element names (conflict avoidance). This is fairly ugly, but that’s extensibility for you. Plus, we don’t require validity anyway, just well-formedness.

> 13. P. 16, section 3.3.9: I would add at the 1st paragraph, that, however,

> some states are mandatory, as becomes clear later on.

 

Changed accordingly.

> 14. P. 16, DTD in section 3.3.9: I think we have a bug here: The DTD

indicates that

>   the states are entities (elements), Example 16, however, indicates that

> they are values (text). Which one is correct? If you use text, you

> cannot enumerate them.

>   (See also e.g. section 3.4.3.1, where “State” refers to “PCDATA”.)

 

They are elements. I fixed the example.

> 15. P. 17, section 3.3.10, parameters “SubCode” and “Description”: These

> should also be marked as “optional” in the text, not only in the DTD.

 

Fixed.

> 16. P. 20, section 3.4.1, 1st paragraph: “determine general information

> about process definitions”: Currently we do not yet have an operation to

> do that. Maybe add “(in future)” at the end of the sentence.

 

Didn’t want to add “in future”, since we’re using Appendix B for that.

But I did modify the wording in that section.

> 17. P. 23, parameter “LastModified”: This should be marked as

“(Optional)”.

Done.

> 18. P. 24, example 13: This seems to refer to example 11. However, it is

not

> consistent, because it does not return all the Response Parameters (they

are not

> marked as optional). Either make them optional or adjust the example.

 

Well, the idea is that an engine can request that only certain parameters be returned. So they’re all optional. But at least one must be present or the element shouldn’t appear at all. I’ve marked them all as optional in the text to hopefully make this more clear. I’ve also changed the name of this element from “ResultDataAttributes” to “ResultDataSet”, for further clarity and to avoid misunderstanding due to conflict with the XML term “attribute”.

> 19. P. 27, sentence before Example 17: “set to true” -> “set to “true” “;

> “returned This ...” -> “returned. This ...”.

 

Fixed. Fixed.

> 20. P. 28, 1st paragraph: “... combines ... into a single operation ....”:

I

> think the reason is just to get better performance, if you do not use such

 

> fine-grained operations via protocols such as http. Maybe we should add

that as a reason.

Added that, but I wasn’t clear about it. So check this please. Thanks.

> 21. P. 29: The “Feature/Function Requirements” and the “Data Types”

explanation

>   seem to be very much related. Maybe they should be just combined into

one

> item “Data handling”.

 

Combined into “Data Requirements”.

> 22. P. 30, last paragraph: Here we could recommend to use the namespace

> mechanism, such that extensions are protected also for future versions.

 

Done.

> 23. P. 37, B.5.1: The wording sounds strange. It says it covers something

> that it does not cover. Adjust the wording.

 

Adjusted wording.

Michael A. Rossi

mailto:mrossi@csc.com

856-983-4400 x4911

 

------------------------------

 

Date:          Tue, 2 May 2000 09:48:55 -0400

From:         Michael Rossi <mrossi@CRUSHER.JCALS.CSC.COM>

Subject:      Re: Comments to the Wf-XML version 1.0 candidate

 

Hollingsworth David wrote:

>

> Michael. Try the following for 3.3.8 Para 1?

>

> “Typically a process is associated with some number of data items specific

> to that process. These data items may represent the properties of the

> Process Instance (Workflow Control or Workflow Relevant data), and/or any

> application related data associated with invoked applications during

process

> enactment (Application data). (These terms are defined within the WfMC

> Glossary [9].)  This collection .....”

 

Excellent. It’s in. Thanks.

> I don’t want to start another debate so if anyone objects to the above,

> please revert to the “target” phrase !!

 

Naturally, any strong objection will be considered. But that sounds fairly safe to me.

> Thanks to both commentors and editor; I feel we are very nearly there.

 

Definitely. Let’s wrap this up ASAP so we can start working on the next version.

Michael A. Rossi

mailto:mrossi@csc.com

856-983-4400 x4911

 

------------------------------

 

End of WORKGROUP4 Digest - 1 May 2000 to 2 May 2000 (#2000-39)

**************************************************************

There is one message totalling 231 lines in this issue.

Topics of the day:

1.   Comments to the Wf-XML version 1.0 candidate

 

----------------------------------------------------------------------

 

Date:          Mon, 1 May 2000 17:01:50 -0400

From:         Michael Rossi <mrossi@CRUSHER.JCALS.CSC.COM>

Subject:      Re: Comments to the Wf-XML version 1.0 candidate

 

Hello All,

I’ve made some changes based on input received thus far and am just about ready to send the spec off for publication. But I do have a couple of remaining questions embedded below.

In addition to the changes noted below I have made the follwoing changes for the 1.0 version:

*   added headers in the examples (I found the keys to be helpful in a walk-through with a newbie)

*   added the definition of the ISOLangs entity (used in the ResponseLang attribute)

*   added two new examples in the header section (2.3.6), for consistency

*   changed “EMPLTY” to “EMPTY” in the Process Status section

*   regenerated the TOC

*   did a spell check

 

You can retrieve the current version (with these changes) from:

http://199.210.109.10/download/Files/pccv3/Wf-XML-1.0.doc

Please see below for more information and provide any further input ASAP.

Thanks.

Weber, Rainer wrote:

>

> My other remarks refer to just a few (hopefully) obvious

> bugs/inconsistencies/...:

>

> 1. P.2: “First printing January 2000”: This should be adjusted for the

final

> version.

 

Changed to “May 2000”.

> 2. P. 5: The change history should be removed for the final version.

 

Done.

> 3. P. 7: The wording of sections 2.3 and 2.4 need to be updated for the

> final version.

 

Done.

> 4. P. 11 (namespace): It should be noted that when using a prefix (such as

> the prefix “wf” in the example), this cannot be validated against a DTD

any

> more.

>     (At least some preprocessor would have to delete that “wf”.)

 

Added wording to that effect.

> 5. P. 12, section 3.3.4, 1st paragraph: “ncessary” -> “necessary”

 

Fixed.

> 6. P. 12, section 3.3.4, 1st paragraph, last sentence: “..., and in the

> interoperability contract for the particular implementation using the

> transport”. I think we should drop that phrase. It seems to indicate that

> interoperability-contract-specific entities should be introduced there.

> We should not widely encourage that other than permitting

> this in general in section 6. To me, this does not seem necessary, at

> least not for HTTP, and I would hope also for the other upcoming

> transport bindings.

 

I agree, phrase dropped.

> 7. P. 13, section 3.3.6, 1st paragraph: “pre-porcessing” ->

“pre-processing”.

Fixed.

> 8. P. 14, parameter “Key”: “... only requiring relative URI ...”: We

should

> indicate relative to “what”, i.e., where the base URI appears. We should

> refer to the transport binding section for that purpose. By only reading

> that sentence, it does not become clear.

 

I may not be clear on how you intended to implement this, Rainer. I had assumed that the base URI would have to be managed (created, stored, retrieved) outside of the message contents to be useful as an abstraction from the transport layer. Thus the current wording:

“It should be noted that this is not required to be an absolute URI. An implementation may wish to maintain base URIs internally, thereby only requiring a relative URI within the message header. In these cases, semantics and mechanisms for processing these relative URIs should be agreed upon in the interoperability contract.”

But I now think you envision it within the transport section of the message. Please elaborate on proposed usage of relative keys and I’ll adjust the wording in the spec accordingly.

> 9. P. 14, section 3.3.7, 1st paragraph, last sentence: “Naming the

operation

> elements in this way .... exchanged in a batch ...”: We should not use

> that for a reason. Firstly, we do not support batch in that version, this

might

> irritate the reader. Secondly, the reason to me is that thus we can

specifiy the

> <OperationName.Request> and the <OperationName.Response> independently and

also validate

> against that specification.

 

Right. I had to step back a bit to rethink this one. But I’ve got it now.

The 1.0 wording should be better.

> 10. P. 14, section 3.3.8, 1st paragraph:  “the subject matter”: Could this

> not easily be confused with the “Subject” of a process instance

> (which also exists, see CreateProcessInstance)? I would use a different

term.

I’ve changed this to “target” for now (for lack of a better word). I think “subject matter” was closer to the point, but I agree that it was potentially conflicting. Other suggestions welcome.

> 11. P .14, section 3.3.8, 1st paragraph: Strictly speaking, also the

> ResultData can be part of the Application data (and maybe also the

Workflow

> Control and the Workflow Relevant data), i.e., application data that are

passed back to the

> caller.

 

Adjusted to reflect ResultData more strongly.

> 12. P. 15, last paragraph: “... the interoperating parties should agree

upon

> ...”: I think this does not only depend on the interoperating parties,

> but also on the specific process definitions. Each one will could have its

own DTD.

I’ve added this:

“If this context and result data varies for each given process definition, separate DTDs may be required for each defined process in order to support full validation.”

I thought of discussing namespace-aware parsers as an alternative, but namespaces aren’t “officially” supposed to be used to reference a DTD for validation. They’re just identifiers used for differentiation of element names (conflict avoidance). This is fairly ugly, but that’s extensibility for you. Plus, we don’t require validity anyway, just well-formedness.

> 13. P. 16, section 3.3.9: I would add at the 1st paragraph, that, however,

> some states are mandatory, as becomes clear later on.

 

Changed accordingly.

> 14. P. 16, DTD in section 3.3.9: I think we have a bug here: The DTD

indicates that

>   the states are entities (elements), Example 16, however, indicates that

> they are values (text). Which one is correct? If you use text, you

> cannot enumerate them.

>   (See also e.g. section 3.4.3.1, where “State” refers to “PCDATA”.)

 

They are elements. I fixed the example.

> 15. P. 17, section 3.3.10, parameters “SubCode” and “Description”: These

> should also be marked as “optional” in the text, not only in the DTD.

 

Fixed.

> 16. P. 20, section 3.4.1, 1st paragraph: “determine general information

> about process definitions”: Currently we do not yet have an operation to

> do that. Maybe add “(in future)” at the end of the sentence.

 

Didn’t want to add “in future”, since we’re using Appendix B for that.

But I did modify the wording in that section.

> 17. P. 23, parameter “LastModified”: This should be marked as

“(Optional)”.

Done.

> 18. P. 24, example 13: This seems to refer to example 11. However, it is

not

> consistent, because it does not return all the Response Parameters (they

are not

> marked as optional). Either make them optional or adjust the example.

 

Well, the idea is that an engine can request that only certain parameters be returned. So they’re all optional. But at least one must be present or the element shouldn’t appear at all. I’ve marked them all as optional in the text to hopefully make this more clear. I’ve also changed the name of this element from “ResultDataAttributes” to “ResultDataSet”, for further clarity and to avoid misunderstanding due to conflict with the XML term “attribute”.

> 19. P. 27, sentence before Example 17: “set to true” -> “set to “true” “;

> “returned This ...” -> “returned. This ...”.

 

Fixed. Fixed.

> 20. P. 28, 1st paragraph: “... combines ... into a single operation ....”:

I

> think the reason is just to get better performance, if you do not use such

 

> fine-grained operations via protocols such as http. Maybe we should add

that as a reason.

Added that, but I wasn’t clear about it. So check this please. Thanks.

> 21. P. 29: The “Feature/Function Requirements” and the “Data Types”

explanation

>   seem to be very much related. Maybe they should be just combined into

one

> item “Data handling”.

 

Combined into “Data Requirements”.

> 22. P. 30, last paragraph: Here we could recommend to use the namespace

> mechanism, such that extensions are protected also for future versions.

 

Done.

> 23. P. 37, B.5.1: The wording sounds strange. It says it covers something

> that it does not cover. Adjust the wording.

 

Adjusted wording.

Michael A. Rossi

mailto:mrossi@csc.com

856-983-4400 x4911

 

------------------------------

 

End of WORKGROUP4 Digest - 28 Apr 2000 to 1 May 2000 (#2000-38)

***************************************************************

There is one message totalling 150 lines in this issue.

Topics of the day:

1.   Comments to the Wf-XML version 1.0 candidate

 

----------------------------------------------------------------------

 

Date:          Thu, 27 Apr 2000 14:20:17 +0200

From:         “Weber, Rainer” <rainer.weber@SAP.COM>

Subject:      Comments to the Wf-XML version 1.0 candidate

 

Dear WG4 participants,

Here are a few things that I noticed when reading the latest version of the Wf-XML document:

My biggest concerns are (and I repeat myself here; if nobody else sees that problem, I will not insist on that):

*   Currently we let it completely open how ContextData and ResultData may be specified.

Even several styles are suggested in the document, many more are imaginable.

This causes a much bigger effort of implementing it than was necessary.  This is because in the worst case you would have to hard-code this according to each interoperability contract (it is easier for the receiver of messages, but much harder for the sender, because it need to support the different flavours).  If we would restrict that (and this is what a standard often does), this effort could be made smaller. We would not use expressive power as far as the data types are concerned, though.

*   The transport-specific use of URIs as keys. As far as I understand that issue, also the use of relative URIs does not solve the problem of transport-dependency completely, because for some URI-schemes the composition of a base URI and a relative URI is not supported (e.g. “mailto://...”).

Similarly, I was thinking if using only the base URI for HTTP POST was better.

My other remarks refer to just a few (hopefully) obvious bugs/inconsistencies/...:

1.   P.2: “First printing January 2000”: This should be adjusted for the final version.

2.   P. 5: The change history should be removed for the final version.

3.   P. 7: The wording of sections 2.3 and 2.4 need to be updated for the final version.

4.   P. 11 (namespace): It should be noted that when using a prefix (such as the prefix “wf” in the example), this cannot be validated against a DTD any more.

(At least some preprocessor would have to delete that “wf”.)

5.   P. 12, section 3.3.4, 1st paragraph: “ncessary” -> “necessary”

6.   P. 12, section 3.3.4, 1st paragraph, last sentence: “..., and in the interoperability contract for the particular implementation using the transport”. I think we should drop that phrase. It seems to indicate that interoperability-contract-specific entities should be introduced there. We should not widely encourage that other than permitting this in general in section 6. To me, this does not seem necessary, at least not for

HTTP, and I would hope also for the other upcoming transport bindings.

7.   P. 13, section 3.3.6, 1st paragraph: “pre-porcessing” -> “pre-processing”.

8.   P. 14, parameter “Key”: “... only requiring relative URI ...”: We should indicate relative to “what”, i.e., where the base URI appears. We should refer to the transport binding section for that purpose. By only reading that sentence, it does not become clear.

9.   P. 14, section 3.3.7, 1st paragraph, last sentence: “Naming the operation elements in this way .... exchanged in a batch ...”: We should not use that for a reason. Firstly, we do not support batch in that version, this might irritate the reader.

Secondly, the

reason to me is that thus we can specifiy the <OperationName.Request> and

the

<OperationName.Response> independently and also validate against that specification.

10.  P. 14, section 3.3.8, 1st paragraph:  “the subject matter”: Could this not easily be confused with the “Subject” of a process instance (which also exists, see

CreateProcessInstance)? I would use a different term.

11.  P .14, section 3.3.8, 1st paragraph: Strictly speaking, also the

ResultData can be

part of the Application data (and maybe also the Workflow Control and the

Workflow

Relevant data), i.e., application data that are passed back to the caller.

12.  P. 15, last paragraph: “... the interoperating parties should agree upon

...”: I think

this does not only depend on the interoperating parties, but also on the

specific

process definitions. Each one will could have its own DTD.

13.  P. 16, section 3.3.9: I would add at the 1st paragraph, that, however, some states are mandatory, as becomes clear later on.

14.  P. 16, DTD in section 3.3.9: I think we have a bug here: The DTD indicates that the states are entities (elements), Example 16, however, indicates that they are values (text). Which one is correct? If you use text, you cannot enumerate them.

(See also e.g. section 3.4.3.1, where “State” refers to “PCDATA”.)

15.  P. 17, section 3.3.10, parameters “SubCode” and “Description”: These should also be marked as   “optional” in the text, not only in the DTD.

16.  P. 20, section 3.4.1, 1st paragraph: “determine general information about process definitions”: Currently we do not yet have an operation to do that. Maybe add “(in future)” at the end of the sentence.

17.  P. 23, parameter “LastModified”: This should be marked as “(Optional)”.

18.  P. 24, example 13: This seems to refer to example 11. However, it is not consistent, because it does not return all the Response Parameters (they are not marked as optional). Either make them optional or adjust the example.

19.  P. 27, sentence before Example 17: “set to true” -> “set to “true” “;

“returned This ...”

*   > “returned. This ...”.

20.  P. 28, 1st paragraph: “... combines ... into a single operation ....”: I think the reason is just to get better performance, if you do not use such fine-grained operations via protocols such as http. Maybe we should add that as a reason.

21.  P. 29: The “Feature/Function Requirements” and the “Data Types” explanation seem to be very much related. Maybe they should be just combined into one item “Data handling”.

22.  P. 30, last paragraph: Here we could recommend to use the namespace mechanism, such that extensions are protected also for future versions.

23.  P. 37, B.5.1: The wording sounds strange. It says it covers something that it does not cover. Adjust the wording.

 

 

 

Best regards,

Rainer Weber

SAP AG

 

------------------------------

 

End of WORKGROUP4 Digest - 26 Apr 2000 to 27 Apr 2000 (#2000-36)

****************************************************************

There is one message totalling 59 lines in this issue.

Topics of the day:

1.   AW: Wf-XML 1.0 Candidate Specification

 

----------------------------------------------------------------------

 

Date:          Tue, 25 Apr 2000 10:58:21 +0200

From:         “Weber, Rainer” <rainer.weber@SAP.COM>

Subject:      AW: Wf-XML 1.0 Candidate Specification

 

Hello Michael,

I think we used True/False if there are only two possiblities (like in logics: “tertium non datur”).  From a pragmatic point of view, Yes/No does not have quite this flavour, it is not as strict. But this is more a matter of taste.  So I would suggest Yes/No/IfError for ResponseRequired and True/Fals for StartImmediately.

Best regards,

Rainer Weber

SAP AG

 

> -----Ursprüngliche Nachricht-----

> Von:  Michael Rossi [SMTP:mrossi@CRUSHER.JCALS.CSC.COM]

> Gesendet am:  Montag, 24. April 2000 19:36

> An:   WORKGROUP4@FTPLIST.AIIM.ORG

> Betreff:      Re: Wf-XML 1.0 Candidate Specification

>

> I wrote:

> >

> > Sunil Sarin wrote:

> > >

> > > In trying to use this spec to update the Wf-XML paper that we are

> writing

> > > (with Jim Hayes, among others), I found the use of Yes/No in one

case

> > > (ResponseRequired) and true/false in another (StartImmediately)

> confusing.

> > > If we still want to adhere to that (I don’t know the history

> > > behind changing the latter from Yes/No), so be it.

> >

> >    This was changed in the edition created after Effat left,

> > 0.9.1 (by Rainer, Marc-Thomas and others?). I believe

> > True/False just seemed to be more consistent with what

> > developers would expect. Thanks for pointing out the

> > incosistency though. I’ll change them all to True/False.

>

>    As I looked into making this change I realized that

ResponseRequired

> can

> currently be Yes, No or IfError. Making this True, False, or IfError

seems

> a

> bit odd. Would we prefer (for consistency’s sake) to do this, or to

make

> StartImmediately Yes/No again?

>

> Michael A. Rossi

> mailto:mrossi@csc.com

> 856-983-4400 x4911

 

------------------------------

 

End of WORKGROUP4 Digest - 24 Apr 2000 to 25 Apr 2000 (#2000-34)

****************************************************************

There is one message totalling 101 lines in this issue.

Topics of the day:

1.   FW: CEOS/NASA Workshop, May 17/18, DC area

 

----------------------------------------------------------------------

 

Date:          Tue, 25 Apr 2000 09:58:16 +0100

From:         Hollingsworth David <David.Hollingsworth@ICL.COM>

Subject:      FW: CEOS/NASA Workshop, May 17/18, DC area

 

I gave an overview presentation on the work of the WfMC to this workshop (CEOS/NASA, London April 12th). Is there a volunteer in the Technical Committee who would be able to participate in their next meeting in the Washington DC area 17/18th May?

For background CEOS is the international Committee of Earth Observation Satellites (NASA is the US representative organisation). They are specifying (amongst other things) a framework IT standard for the co-ordinated distributed processing of satellite based image data. One aspect involves the potential use of workflow capability to co-ordinate the chaining of processing services operating on this data.

The following email from George Percival provides more background and a preliminary agenda for their upcoming meeting.

I’m happy to provide more background (as would be George) if someone is interested and able to contribute.

Thanks & rgds, Dave Hollingsworth

-----Original Message-----

From:         George Percivall [mailto:george@sgt-inc.com]

Sent:          21 April 2000 19:30

To:              David Hollingsworth

Subject:      CEOS/NASA Workshop, May 17/18, DC area

 

 

David,

It was a pleasure to meet you last week at UCL.  And thanks again for making the presentation of WfMC to our CEOS meeting.

Based on the presentation and discussion last week it make sense to continue the discussion of the application of WfMC technology to the topic of Service Chaining.  There will be a workshop in the Washington DC area on May 17th and 18th.  You mentioned that there may be someone in Boston who could represent WfMC at this CEOS/NASA workshop.

A preliminary plan for the workshop follows this message.  The workshop is based on part on a survey of Service Chaining technology that was conducted to support three inter-related activities:

*   OpenGIS Consortium Service Architecture SIG

*   ISO TC211 Geographic Information Services (ISO 19119)

*   CEOS Data Services Task Team.

The results of the survey in draft form can be found at:

ftp://lyta.gsfc.nasa.gov/outgoing/dstt/ChainingSurvey.doc

 

Please let me know of WfMC’s interest in participating in this workshop.

Regards,

George Percivall

NASA/GSFC - SGT, inc.

 

---------------------------------------------------------------------------

-

 

Services Workshop Proposed Agenda topics :

Concept talks

*   TC 19119 (Services Standard) Overview

*   Work Flow Analyses

*   Service metadata

*   GCMD Services

*   Others?

 

Current Implementations/Vendor Products - Have presentations from

different

vendors & agency implementations to see the current state of technology

 

Current Applications - Analyze real science applications to validate the Services modeling work being done and see how much of the current applications’ needs are covered by current implementations & technologies.

*   GOFC

*   Digital Earth ?

*   US Army TEC applications ?

*   NIMA applications ?

*   USGS/FGDC applications?

*   other science applications ??

 

Brainstorming Session

*   Provide feedback to the current services modeling work being done

*   assess what is there now with services

*   assess what is needed but hard to do - challenges

 

_________________________________________________________

George Percivall                                SGT, inc.

percivall@gsfc.nasa.gov                    (301) 614-8600

http://sgt.sgt-inc.com/~george         fax (301) 614-8601

7701 Greenbelt Rd.,  Suite 400,  Greenbelt MD, 20770  USA

 

------------------------------

 

End of WFMC_TC Digest - 27 Jan 2000 to 25 Apr 2000 (#2000-2)

************************************************************

There is one message totalling 8192 lines in this issue.
<LONG CODED DOC HAS BEEN DELETED. PLEASE APPLY TO AUTHOR FOR ORIGINAL>

 

Topics of the day:

 

  1. Wf-XML 1.0 Candidate Specification

 

----------------------------------------------------------------------

 

Date:    Thu, 13 Apr 2000 13:22:04 -0400

From:    Michael Rossi <mrossi@CRUSHER.JCALS.CSC.COM>

Subject: Wf-XML 1.0 Candidate Specification

 

This message is in MIME format. Since your mail reader does not understand

this format, some or all of this message may not be legible.

 

------_=_NextPart_000_01BFA56C.CD050ED8

Content-Type: text/plain;

        charset="iso-8859-1"

 

Hello All,

   After much discussion and work on the specification, I believe all agreed

upon changes have been made in this latest version, 0.9.4. Please take some

time to review this document carefully from beginning to end. I know you've

read it many times before, but please treat it as an entirely new document

so that we don't miss anything that may have become inappropriate through

the course of many changes.

 

   The only things that will change for publication purposes are the usual

editorial touch-ups; version number, date, remove change history, etc. Does

anyone know what the "first printing" date is meant to imply? I'm inclined

to change this to April 2000 unless otherwise directed.

 

   Laslty, there is currently one known point of contention, Rainer's

suggestion to store base and relative keys separately. This version leaves

open the _possibility_ of doing this if so stated in an interoperability

contract. However, Rainer would like to see a stronger statement. Without

further input from the group in favor of making changes in this area, the

current approach will remain. So please consider the impact of implementing

this spec carefully and let me know if we need to do more.

 

   I'd like to ask that further input be received on this list by early next

week. Hopefully, we can then get 1.0 out to the world by this time next

week. Thanks for all your patience and support in this process. It can't

happen without you.

 

Michael A. Rossi

mrossi@csc.com <mailto:mrossi@csc.com>

856-983-4400 x4911

 

End of WORKGROUP4 Digest - 10 Apr 2000 to 13 Apr 2000 (#2000-31)

 

There is one message totalling 609 lines in this issue.

Topics of the day:

1.   Paper on security

 

----------------------------------------------------------------------

 

Date:          Mon, 10 Apr 2000 10:05:28 -0700

From:         “Smith, Ned” <ned.smith@INTEL.COM>

Subject:      Paper on security

 

This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible.
<LONG CODED DOC HAS BEEN DELETED. PLEASE APPLY TO AUTHOR FOR ORIGINAL>

 

------_=_NextPart_000_01BFA30E.F9DA5139

Content-Type: text/plain;

charset=”ISO-8859-1”

WFMC members,

At the last WFMC meeting I promised to provide some background information on security and how it relates to work being done in the WFMC. Attached is a paper which provides some historical background on public key infrastructure. It describes some fundamental disconnects between the original objectives of inventors of public key crypto and current practices with X.509/X.500.

I plan to follow up with another paper describing in more detail the importance of focusing attention on authorization of roles rather than of proving identity. Intuitively, process modelling typically describes roles and activities. X.509 focuses on associating identity with organizations. In other words its goals are to distribute elements of the resource model rather than distributing elements of the process model. Workflow automation appears to be all about distributing the process model such that multiple people/agents are able to work together executing a common process.

I’m posting to WG4 because there appears to be the most activity here.

Regards,

Ned

 

 

 

 

 

------_=_NextPart_000_01BFA30E.F9DA5139

Content-Type: application/octet-stream;

name=”compnets-pki-1.ZIP” Content-Transfer-Encoding: base64 Content-Disposition: attachment;

filename=”compnets-pki-1.ZIP”

 

------------------------------

 

End of WORKGROUP4 Digest - 7 Apr 2000 to 10 Apr 2000 (#2000-30)

 

There is one message totalling 21 lines in this issue.

Topics of the day:

1.   Named vs. Unnamed Parameters

 

----------------------------------------------------------------------

 

Date:          Tue, 4 Apr 2000 14:59:16 -0400

From:         Michael Rossi <mrossi@CRUSHER.JCALS.CSC.COM>

Subject:      Re: Named vs. Unnamed Parameters

 

Well it appears that the vote is in. We cannot impose any restrictions on Contex and Result Data in the standard. I also don’t see any strong desire to subtype this data into process- or application-specific. Therefore, we will leave the content of these elements undefined. I will however, make the intent of this data as clear as possible in the spec, with several examples of potential usage. The spec will also recommend appropriate usage of namespaces and industry standard markup wherever possible in order to help differentiate and more easily process this information.

Michael A. Rossi

mailto:mrossi@csc.com

856-983-4400 x4911

 

------------------------------

 

End of WORKGROUP4 Digest - 3 Apr 2000 to 4 Apr 2000 (#2000-28)

**************************************************************

 

There are 2 messages totalling 223 lines in this issue.

Topics of the day:

1. Named vs. Unnamed Parameters (2)

 

----------------------------------------------------------------------

 

Date:          Mon, 3 Apr 2000 08:11:43 -0700

From:         Keith Swenson <kswenson@MS2.COM>

Subject:      Re: Named vs. Unnamed Parameters

 

This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible.

------_=_NextPart_001_01BF9D7E.EBDB5BC8

Content-Type: text/plain;

charset=”iso-8859-1”

Many thanks to Michael zur Muehlen, Michael Rossi, and Rainer Weber for taking the time to give us three proposals for handling context/result data.

It appears that in Rainer’s implementation, a tag can either be a name or a type.  M.z.M. has shown adequately that identification of the individual members of a collection of structured values can be done a number of different ways.  If the value absolutely must have a name (identifier) then I would strongly recommend the approach where each tag has an identifier attribute.  This seems more in line with the arguement that (the other) Michael made about using attributes when the value is a modifier of an entity, and not another entity itself.

But I easily see that case that some interactions might be set up where no such name is needed or even wanted.  Take for example an interaction where company A submits a purchase order to company B.  (Company B, of course, specifies the format of the data, so anything it can consume should be sufficient.)  In this example, company B wants some header information, and then a list of line items for the purchase order.  e.g.:

<ContextData>

<Customer>

        ...

</Customer>

<Item>

<CatalogNumber>62831</CatalogNumber>

<Quantity>2</Quantitiy>

</Item>

<Item>

<CatalogNumber>2811Z9</CatalogNumber>

<Quantity>4</Quantitiy>

</Item>

<Item>

<CatalogNumber>2831</CatalogNumber>

<Quantity>1</Quantitiy>

</Item>

<Item>

<CatalogNumber>412831</CatalogNumber>

<Quantity>1</Quantitiy>

</Item>

<Item>

<CatalogNumber>747731-P</CatalogNumber>

<Quantity>2</Quantitiy>

</Item>

</ContextData>

 

In this case, generation of a name would simply be unwelcome overhead.  In this case, the data is clearly a list of line items, each equivalent.  The order of the items can be preserved.  The individual items can easily be addressed by their numerical position in the list.

Rainer, is it possible that the reason you require the name is that your implementation needs it for an intermediate representation between the XML and the workflow engine?  Is it the intermediate representation that requires this name?  I am just guessing here, because the XML clearly does not require it, nor do the DOM models that many XML parsers output.  Nevertheless, if you need it, I recommend the ID= attribute as Michael has suggested.

Clearly some companies will decide to pass named structures in order to talk to them.  (One might assume that in order to invoke a process on SAP such a named structure will be required.)  There is no problem with this.  But there could be quite a bit of harm in *requiring* this for every implementation since many already agreed upon structures would be excluded.  Alternately, if you really need a name at the root level, why not, then, consider the tag <ContextData> as the name, with everything inside it as the value?

In conclusion, I agree wholly with the message from Michael zur Muehlen.

*   Keith

 

------_=_NextPart_001_01BF9D7E.EBDB5BC8

Content-Type: text/html;

charset=”iso-8859-1”

Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 3.2//EN”>

<HTML>

<HEAD>

<META HTTP-EQUIV=”Content-Type” CONTENT=”text/html;

charset=iso-8859-1”>

<META NAME=”Generator” CONTENT=”MS Exchange Server version

5.5.2650.12”>

<TITLE>RE: Named vs. Unnamed Parameters</TITLE>

</HEAD>

<BODY>

 

<P><FONT SIZE=2>Many thanks to Michael zur Muehlen, Michael Rossi,

and Rainer Weber for taking the time to give us three proposals for

handling context/result data.</FONT></P>

<P><FONT SIZE=2>It appears that in Rainer’s implementation, a tag can

either be a name or a type.&nbsp; M.z.M. has shown adequately that

identification of the individual members of a collection of structured

values can be done a number of different ways.&nbsp; If the value

absolutely must have a name (identifier) then I would strongly

recommend the approach where each tag has an identifier

attribute.&nbsp; This seems more in line with the arguement that (the

other) Michael made about using attributes when the value is a modifier

of an entity, and not another entity itself.</FONT></P>

<P><FONT SIZE=2>But I easily see that case that some interactions

might be set up where no such name is needed or even wanted.&nbsp; Take

for example an interaction where company A submits a purchase order to

company B.&nbsp; (Company B, of course, specifies the format of the

data, so anything it can consume should be sufficient.)&nbsp; In this

example, company B wants some header information, and then a list of

line items for the purchase order.&nbsp; e.g.: </FONT></P>

<P><FONT SIZE=2>&lt;ContextData&gt;</FONT>

<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; &lt;Customer&gt;</FONT>

<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

...</FONT>

<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; &lt;/Customer&gt;</FONT>

<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; &lt;Item&gt;</FONT>

<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

&lt;CatalogNumber&gt;62831&lt;/CatalogNumber&gt;</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>&nbsp;

&lt;Quantity&gt;2&lt;/Quantitiy&gt;</FONT>

<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; &lt;/Item&gt;</FONT>

<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; &lt;Item&gt;</FONT>

<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

&lt;CatalogNumber&gt;2811Z9&lt;/CatalogNumber&gt;</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>&nbsp;

&lt;Quantity&gt;4&lt;/Quantitiy&gt;</FONT>

<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; &lt;/Item&gt;</FONT>

<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; &lt;Item&gt;</FONT>

<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

&lt;CatalogNumber&gt;2831&lt;/CatalogNumber&gt;</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>&nbsp;

&lt;Quantity&gt;1&lt;/Quantitiy&gt;</FONT>

<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; &lt;/Item&gt;</FONT>

<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; &lt;Item&gt;</FONT>

<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

&lt;CatalogNumber&gt;412831&lt;/CatalogNumber&gt;</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>&nbsp;

&lt;Quantity&gt;1&lt;/Quantitiy&gt;</FONT>

<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; &lt;/Item&gt;</FONT>

<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; &lt;Item&gt;</FONT>

<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

&lt;CatalogNumber&gt;747731-P&lt;/CatalogNumber&gt;</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=2>&nbsp;

&lt;Quantity&gt;2&lt;/Quantitiy&gt;</FONT>

<BR><FONT SIZE=2>&nbsp;&nbsp;&nbsp; &lt;/Item&gt;</FONT>

<BR><FONT SIZE=2>&lt;/ContextData&gt;</FONT>

</P>

<BR>

 

<P><FONT SIZE=2>In this case, generation of a name would simply be

unwelcome overhead.&nbsp; In this case, the data is clearly a list of

line items, each equivalent.&nbsp; The order of the items can be

preserved.&nbsp; The individual items can easily be addressed by their

numerical position in the list.</FONT></P>

<P><FONT SIZE=2>Rainer, is it possible that the reason you require

the name is that your implementation needs it for an intermediate

representation between the XML and the workflow engine?&nbsp; Is it the

intermediate representation that requires this name?&nbsp; I am just

guessing here, because the XML clearly does not require it, nor do the

DOM models that many XML parsers output.&nbsp; Nevertheless, if you

need it, I recommend the ID= attribute as Michael has

suggested.</FONT></P>

<P><FONT SIZE=2>Clearly some companies will decide to pass named

structures in order to talk to them.&nbsp; (One might assume that in

order to invoke a process on SAP such a named structure will be

required.)&nbsp; There is no problem with this.&nbsp; But there could

be quite a bit of harm in *requiring* this for every implementation

since many already agreed upon structures would be excluded.&nbsp;

Alternately, if you really need a name at the root level, why not,

then, consider the tag &lt;ContextData&gt; as the name, with everything

inside it as the value?</FONT></P>

<P><FONT SIZE=2>In conclusion, I agree wholly with the message from

Michael zur Muehlen.</FONT>

<BR><FONT SIZE=2>-Keith</FONT>

</P>

 

</BODY>

</HTML>

------_=_NextPart_001_01BF9D7E.EBDB5BC8--

 

------------------------------

 

Date:          Mon, 3 Apr 2000 19:18:28 +0100

From:         Hollingsworth David <David.Hollingsworth@ICL.COM>

Subject:      Re: Named vs. Unnamed Parameters

 

I’m inherently nervous about placing any unnecessary restrictions on the Context data - simply because we have no control over what might get produced (or be agreed bilaterally) and may need to be included as part of a payload passing through the Workflow domain to an application. Rainer makes a fair point about the lack of such clarity in other interface specs - but I think it is the first time we have seriously considered the implications of embedding other (application data) data definitions within an interface definition. Personally I am happy with (both) Michael’s suggestions. If we have to invent an element type to convey unnamed parameters “application data” (i.e. non-WFMS sensitive data) or something similar is ok by me.

Rgds, Dave H

Dave Hollingsworth

*   ICL, Forest Road, Feltham, Middx, TW13 7EJ

*   Tel: (+44) 181 730 4112

*   Fax: (+44) 181 730 4151

*   Mobile: 07867 831803

*   E-mail: david.hollingsworth@icl.com

 

------------------------------

 

End of WORKGROUP4 Digest - 31 Mar 2000 to 3 Apr 2000 (#2000-27)

***************************************************************

 

There are 3 messages totalling 1538 lines in this issue.

 

Topics of the day:

 

  1. Named vs. Unnamed Parameters

  2. Proposal for ContextData and ResultData

  3. Context and Result Data proposal

 

----------------------------------------------------------------------

 

Date:    Fri, 31 Mar 2000 17:46:56 +0200

From:    Michael zur Muehlen <ismizu@WI.UNI-MUENSTER.DE>

Subject: Named vs. Unnamed Parameters

 

This message is in MIME format. Since your mail reader does not understand

this format, some or all of this message may not be legible.

 

------_=_NextPart_000_01BF9B28.58D23C80

Content-Type: text/plain;

        charset="ISO-8859-1"

 

Hi,

 

as a follow-up to our discussion on named vs.

unnamed parameters in the context data section

I attach a Word file with some food for thought.

 

Have a nice weekend

 

Mizu

---------------------------------------------

Michael zur Muehlen

University of Muenster

Department of Information Systems

Steinfurter Str. 109 - 48149 Muenster - Germany

Phone: +49-(0)251-8338-080 - Fax.: +49-(0)251-8328-080

Mobile: +49-(0)171-801-9275 - E-Mail: ismizu@wi.uni-muenster.de

http://www-wi.uni-muenster.de/is/mitarbeiter/ismizu

--- ICQ# 12371941 --- PGP-Key available upon request ---

<LONG CODED DOC HAS BEEN DELETED. PLEASE APPLY TO AUTHOR FOR ORIGINAL>

 

------_=_NextPart_000_01BF9B28.58D23C80

Content-Type: application/msword;

        name="Named vs. Unnamed Parameters.doc"

Content-Transfer-Encoding: base64

Content-Disposition: attachment;

        filename="Named vs. Unnamed Parameters.doc"

Content-Location: ATT-0-AA3255B66F06D411973700A0C944AC70-N

        AMEDV%7E1.DOC

------_=_NextPart_000_01BF9B3D.D1E26A10--

 

------------------------------

 

End of WORKGROUP4 Digest - 30 Mar 2000 to 31 Mar 2000 (#2000-26)

 

There is one message totalling 56 lines in this issue.

Topics of the day:

1.   FW: XML protocol comparisons

 

----------------------------------------------------------------------

 

Date:          Thu, 30 Mar 2000 13:32:00 -0500

From:         Michael Rossi <mrossi@CRUSHER.JCALS.CSC.COM>

Subject:      FW: XML protocol comparisons

 

Just an FYI for those who haven’t jumped onto xml-dist-app yet. Eric at the W3C has started a very interesting web page exploring most everything (and undoubtedly more than) we should be keeping an eye on these days. I’ll get him some updated information, but feel free to check out this site and contact him if you have useful updates:

http://www.w3.org/2000/03/29-XML-protocol-matrix

Michael A. Rossi

mailto:mrossi@csc.com

856-983-4400 x4911

 

 

-----Original Message-----

From:         Eric Prud’hommeaux [mailto:eric@w3.org]

Sent:          Wednesday, March 29, 2000 8:17 PM

To:              xml-dist-app@w3.org

Subject:      XML protocol comparisons

 

 

I put together a comparison of a bunch of XML protocols,

SOAP [http://www.w3.org/2000/03/29-XML-protocol-matrix#SOAP]

ICE [http://www.w3.org/2000/03/29-XML-protocol-matrix#ICE]

WDDX [http://www.w3.org/2000/03/29-XML-protocol-matrix#WDDX]

BizTalk [http://www.w3.org/2000/03/29-XML-protocol-matrix#BizTalk]

IOTP [http://www.w3.org/2000/03/29-XML-protocol-matrix#IOTP]

TIP [http://www.w3.org/2000/03/29-XML-protocol-matrix#TIP] WfXML [http://www.w3.org/2000/03/29-XML-protocol-matrix#WfXML] ebXML [http://www.w3.org/2000/03/29-XML-protocol-matrix#ebXML] XMI [http://www.w3.org/2000/03/29-XML-protocol-matrix#XMI]

for everyone to discuss/dispute. It is said that the best way to get a question answered on usenet is to post an incorrect answer. Persuant to that, I have not done extensive readings of some of the protocol papers during my characterizations, but at least they’re all there in a forum where we can compare apples and fruit baskets.

I’ll be adding more dimensions and would like feedback on what people wish to compare. Also, I’d like to have anchor-rich HTML versions of the documents so I can point to specific parts of the spec as supporting evidence.

 

--

*   eric

 

(eric@w3.org)

 

------------------------------

 

End of WORKGROUP4 Digest - 29 Mar 2000 to 30 Mar 2000 (#2000-25)

****************************************************************

There are 3 messages totalling 1680 lines in this issue.

 

Topics of the day:

 

  1. Wf-XML paper for IEEE Internet Computing

  2. What needs to be done to finish Wf-XML 1.0?  Conference Call.

  3. Impending release of Wf-XML Version 1.0

 

----------------------------------------------------------------------

 

Date:    Wed, 29 Mar 2000 00:15:28 -0500

From:    Layna Fischer <layna@MEDIAONE.NET>

Subject: Wf-XML paper for IEEE Internet Computing

 

This is a multi-part message in MIME format.

 

------=_NextPart_000_0000_01BF9913.E3AC2000

Content-Type: text/plain;

        charset="iso-8859-1"

Content-Transfer-Encoding: quoted-printable

 

Dear Sunil:

=20

Please send me this separately, when the last edits are in, as a WinWord =

or PDF, I was not able to decode your MIME attachment.=20

=20

Do I assume correctly that you want this on the Public side of the web =

site? I will place it on the Members Only side as well.

=20

Thanks

=20

L-)

=20

Layna Fischer, General Manager

Workflow Management Coalition (Wf MC)

2436 North Federal Highway #374, Lighthouse Point, FL 33064, USA

Phone +1 954 782 3376, Fax +1 954 782 6365

email: layna@wfmc.org             http://www.wfmc.org/

=20

=20

NextPart_000_016B_01BF98BD.98220330

Content-Type: text/plain;

        charset=3D"iso-8859-1"

Content-Transfer-Encoding: 7bit

=20

Enclosed is a close to final version of the paper that we (Hayes, =

Peyrovian,

Sarin, Schmidt, Swenson, Weber) sent to the publishers; they will be =

doing

some cleanup and editing before it appears in the May/June issue.  If =

anyone

has any last-minute factual corrections, including giving appropriate

credit, please let me know.

=20

If the Secretariat is watching, can you put this up on the Web site?

Thanks,

    Sunil

=20

 

------=_NextPart_000_0000_01BF9913.E3AC2000

Content-Type: text/html;

        charset="iso-8859-1"

Content-Transfer-Encoding: quoted-printable

 

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =

xmlns:w=3D"urn:schemas-microsoft-com:office:word" =

xmlns=3D"http://www.w3.org/TR/REC-html40">

 

<head>

<meta http-equiv=3DContent-Type content=3D"text/html; =

charset=3Diso-8859-1">

<meta name=3DProgId content=3DWord.Document>

<meta name=3DGenerator content=3D"Microsoft Word 9">

<meta name=3DOriginator content=3D"Microsoft Word 9">

<link rel=3DFile-List href=3D"cid:filelist.xml@01BF9913.DB73F020">

<!--[if gte mso 9]><xml>

 <o:DocumentProperties>

  <o:Revision>1</o:Revision>

  <o:TotalTime>4</o:TotalTime>

  <o:Created>2000-03-29T05:10:00Z</o:Created>

  <o:Pages>1</o:Pages>

  <o:Company>Future Strategies Inc</o:Company>

  <o:Lines>1</o:Lines>

  <o:Paragraphs>1</o:Paragraphs>

  <o:Version>9.3821</o:Version>

 </o:DocumentProperties>

 <o:OfficeDocumentSettings>

  <o:RelyOnVML/>

  <o:DoNotRelyOnCSS/>

 </o:OfficeDocumentSettings>

</xml><![endif]--><!--[if gte mso 9]><xml>

 <w:WordDocument>

  <w:View>Normal</w:View>

  <w:Zoom>0</w:Zoom>

  <w:DocumentKind>DocumentEmail</w:DocumentKind>

  <w:EnvelopeVis/>

 </w:WordDocument>

</xml><![endif]-->

<style>

<!--

 /* Font Definitions */

@font-face

        {font-family:Wingdings;

        panose-1:5 0 0 0 0 0 0 0 0 0;

        mso-font-charset:2;

        mso-generic-font-family:auto;

        mso-font-pitch:variable;

        mso-font-signature:0 268435456 0 0 -2147483648 0;}

@font-face

        {font-family:"Arial Narrow";

        panose-1:2 11 5 6 2 2 2 3 2 4;

        mso-font-charset:0;

        mso-generic-font-family:swiss;

        mso-font-pitch:variable;

        mso-font-signature:647 0 0 0 159 0;}

@font-face

        {font-family:Tahoma;

        panose-1:2 11 6 4 3 5 4 4 2 4;

        mso-font-charset:0;

        mso-generic-font-family:swiss;

        mso-font-pitch:variable;

        mso-font-signature:16792199 0 0 0 65791 0;}

@font-face

        {font-family:"Franklin Gothic Book";

        panose-1:2 11 5 3 2 1 2 2 2 4;

        mso-font-charset:0;

        mso-generic-font-family:swiss;

        mso-font-pitch:variable;

        mso-font-signature:647 0 0 0 159 0;}

@font-face

        {font-family:Garamond;

        panose-1:2 2 4 4 3 3 1 1 8 3;

        mso-font-charset:0;

        mso-generic-font-family:roman;

        mso-font-pitch:variable;

        mso-font-signature:647 0 0 0 159 0;}

@font-face

        {font-family:"Bookman Old Style";

        panose-1:2 5 6 4 5 5 5 2 2 4;

        mso-font-charset:0;

        mso-generic-font-family:roman;

        mso-font-pitch:variable;

        mso-font-signature:647 0 0 0 159 0;}

@font-face

        {font-family:Palatino;

        panose-1:0 0 0 0 0 0 0 0 0 0;

        mso-font-alt:"Book Antiqua";

        mso-font-charset:0;

        mso-generic-font-family:roman;

        mso-font-format:other;

        mso-font-pitch:variable;

        mso-font-signature:3 0 0 0 1 0;}

@font-face

        {font-family:"Century Schoolbook";

        panose-1:2 4 6 4 5 5 5 2 3 4;

        mso-font-charset:0;

        mso-generic-font-family:roman;

        mso-font-pitch:variable;

        mso-font-signature:647 0 0 0 159 0;}

 /* Style Definitions */

p.MsoNormal, li.MsoNormal, div.MsoNormal

        {mso-style-parent:"";

        margin:0in;

        margin-bottom:.0001pt;

        mso-pagination:widow-orphan;

        font-size:10.0pt;

        mso-bidi-font-size:12.0pt;

        font-family:Arial;

        mso-fareast-font-family:"Times New Roman";

        mso-bidi-font-family:"Times New Roman";}

h1

        {margin-top:12.0pt;

        margin-right:0in;

        margin-bottom:12.0pt;

        margin-left:0in;

        text-align:center;

        mso-pagination:widow-orphan;

        page-break-after:avoid;

        mso-outline-level:1;

        mso-hyphenate:none;

        font-size:18.0pt;

        mso-bidi-font-size:16.0pt;

        font-family:Arial;

        mso-font-kerning:16.0pt;}

h2

        {mso-style-parent:"Body Text";

        margin-top:9.0pt;

        margin-right:0in;

        margin-bottom:3.0pt;

        margin-left:0in;

        mso-pagination:widow-orphan lines-together;

        page-break-after:avoid;

        mso-outline-level:2;

        mso-hyphenate:none;

        font-size:12.0pt;

        mso-bidi-font-size:10.0pt;

        font-family:"Arial Narrow";

        font-variant:small-caps;

        color:black;

        mso-font-kerning:8.0pt;

        font-weight:normal;

        mso-bidi-font-weight:bold;}

h3

        {mso-style-next:"Body Text";

        margin:0in;

        margin-bottom:.0001pt;

        mso-line-height-alt:10.0pt;

        mso-pagination:widow-orphan lines-together;

        page-break-after:avoid;

        mso-outline-level:3;

        font-size:11.0pt;

        mso-bidi-font-size:12.0pt;

        font-family:Arial;

        mso-bidi-font-family:"Times New Roman";

        letter-spacing:-.3pt;

        mso-font-kerning:10.0pt;

        text-shadow:auto;

        mso-ansi-language:EN-GB;

        mso-bidi-font-weight:normal;}

h4

        {mso-style-parent:"Body Text";

        margin-top:3.0pt;

        margin-right:0in;

        margin-bottom:0in;

        margin-left:0in;

        margin-bottom:.0001pt;

        line-height:10.0pt;

        mso-pagination:widow-orphan;

        page-break-after:avoid;

        mso-outline-level:4;

        font-size:10.0pt;

        font-family:Garamond;

        color:black;

        mso-font-kerning:8.0pt;

        mso-bidi-font-weight:normal;

        font-style:italic;

        mso-bidi-font-style:normal;}

h5

        {mso-style-parent:"Body Text";

        margin-top:.25in;

        margin-right:.25in;

        margin-bottom:0in;

        margin-left:.25in;

        margin-bottom:.0001pt;

        mso-pagination:widow-orphan;

        page-break-after:avoid;

        mso-outline-level:5;

        font-size:11.0pt;

        mso-bidi-font-size:10.0pt;

        font-family:"Arial Narrow";

        mso-bidi-font-family:Arial;

        color:black;

        letter-spacing:-.1pt;

        mso-font-kerning:8.0pt;

        mso-ansi-language:EN-GB;

        mso-bidi-font-weight:normal;}

h6

        {mso-style-parent:"Body Text";

        margin-top:3.0pt;

        margin-right:0in;

        margin-bottom:12.0pt;

        margin-left:0in;

        text-align:center;

        mso-line-height-alt:12.0pt;

        mso-pagination:widow-orphan;

        mso-outline-level:6;

        font-size:14.0pt;

        mso-bidi-font-size:11.0pt;

        font-family:"Arial Narrow";

        color:black;

        mso-font-kerning:8.0pt;}

p.MsoToc4, li.MsoToc4, div.MsoToc4

        {mso-style-update:auto;

        mso-style-next:Normal;

        margin:0in;

        margin-bottom:.0001pt;

        mso-pagination:widow-orphan;

        tab-stops:right 5.0in;

        font-size:10.0pt;

        mso-bidi-font-size:18.0pt;

        font-family:Arial;

        mso-fareast-font-family:"Times New Roman";

        mso-bidi-font-family:"Times New Roman";}

p.MsoHeader, li.MsoHeader, div.MsoHeader

        {mso-style-parent:"Body Text";

        margin-top:3.0pt;

        margin-right:-.55pt;

        margin-bottom:3.0pt;

        margin-left:0in;

        text-align:center;

        mso-pagination:widow-orphan;

        mso-hyphenate:none;

        tab-stops:center 3.0in right 6.0in;

        font-size:11.0pt;

        mso-bidi-font-size:12.0pt;

        font-family:Arial;

        mso-fareast-font-family:"Times New Roman";

        color:black;}

p.MsoFooter, li.MsoFooter, div.MsoFooter

        {mso-style-parent:"Body Text";

        margin-top:3.0pt;

        margin-right:0in;

        margin-bottom:3.0pt;

        margin-left:0in;

        text-align:center;

        line-height:10.0pt;

        mso-pagination:widow-orphan;

        tab-stops:center 3.0in right 6.0in;

        border:none;

        mso-border-top-alt:solid #999999 2.25pt;

        padding:0in;

        mso-padding-alt:1.0pt 0in 0in 0in;

        font-size:10.0pt;

        font-family:"Arial Narrow";

        mso-fareast-font-family:"Times New Roman";

        mso-bidi-font-family:"Times New Roman";

        color:gray;

        mso-font-kerning:8.0pt;

        mso-bidi-font-weight:bold;}

p.MsoCaption, li.MsoCaption, div.MsoCaption

        {mso-style-parent:"Body Text";

        margin-top:3.0pt;

        margin-right:0in;

        margin-bottom:6.0pt;

        margin-left:0in;

        mso-pagination:widow-orphan;

        font-size:9.0pt;

        mso-bidi-font-size:10.0pt;

        font-family:"Bookman Old Style";

        mso-fareast-font-family:"Times New Roman";

        mso-bidi-font-family:"Times New Roman";

        color:black;

        letter-spacing:-.4pt;

        mso-font-kerning:8.0pt;

        font-weight:bold;

        font-style:italic;

        mso-bidi-font-style:normal;}

p.MsoTof, li.MsoTof, div.MsoTof

        {margin-top:0in;

        margin-right:1.0in;

        margin-bottom:6.0pt;

        margin-left:24.0pt;

        text-indent:-24.0pt;

        mso-pagination:widow-orphan;

        font-size:10.0pt;

        font-family:"Century Schoolbook";

        mso-fareast-font-family:"Times New Roman";

        mso-bidi-font-family:"Times New Roman";

        color:#FF6600;}

p.MsoToa, li.MsoToa, div.MsoToa

        {mso-style-parent:"Body Text";

        margin-top:3.0pt;

        margin-right:0in;

        margin-bottom:3.0pt;

        margin-left:12.0pt;

        text-align:justify;

        text-indent:-12.0pt;

        line-height:10.0pt;

        mso-pagination:widow-orphan;

        font-size:10.0pt;

        font-family:Garamond;

        mso-fareast-font-family:"Times New Roman";

        mso-bidi-font-family:"Times New Roman";

        color:#FF6600;

        mso-font-kerning:8.0pt;}

p.MsoListBullet, li.MsoListBullet, div.MsoListBullet

        {mso-style-update:auto;

        mso-style-parent:"Body Text";

        margin-top:0in;

        margin-right:0in;

        margin-bottom:3.0pt;

        margin-left:.5in;

        text-indent:-.25in;

        line-height:12.0pt;

        mso-line-height-rule:exactly;

        mso-pagination:widow-orphan;

        mso-list:l4 level1 lfo21;

        tab-stops:list .5in;

        font-size:10.0pt;

        font-family:"Franklin Gothic Book";

        mso-fareast-font-family:"Times New Roman";

        mso-bidi-font-family:"Times New Roman";

        color:black;

        mso-font-kerning:8.0pt;

        mso-ansi-language:EN-GB;

        mso-fareast-language:FR;

        layout-grid-mode:line;}

p.MsoListNumber, li.MsoListNumber, div.MsoListNumber

        {margin-top:0in;

        margin-right:1.0in;

        margin-bottom:0in;

        margin-left:.25in;

        margin-bottom:.0001pt;

        text-indent:-.25in;

        mso-pagination:widow-orphan;

        mso-list:l1 level1 lfo16;

        tab-stops:list .25in;

        font-size:10.0pt;

        font-family:Arial;

        mso-fareast-font-family:"Times New Roman";

        mso-bidi-font-family:"Times New Roman";}

p.MsoListBullet2, li.MsoListBullet2, div.MsoListBullet2

        {mso-style-update:auto;

        mso-style-parent:"Body Text";

        margin-top:0in;

        margin-right:0in;

        margin-bottom:0in;

        margin-left:.75in;

        margin-bottom:.0001pt;

        text-indent:-.25in;

        line-height:10.0pt;

        mso-pagination:widow-orphan;

        mso-list:l9 level1 lfo10;

        tab-stops:.5in list .75in;

        font-size:10.0pt;

        font-family:Garamond;

        mso-fareast-font-family:"Times New Roman";

        mso-bidi-font-family:"Times New Roman";

        color:black;

        mso-font-kerning:8.0pt;}

p.MsoBodyText, li.MsoBodyText, div.MsoBodyText

        {margin-top:3.0pt;

        margin-right:0in;

        margin-bottom:3.0pt;

        margin-left:0in;

        text-align:justify;

        line-height:10.0pt;

        mso-pagination:widow-orphan;

        font-size:10.0pt;

        font-family:Garamond;

        mso-fareast-font-family:"Times New Roman";

        mso-bidi-font-family:"Times New Roman";

        color:black;

        mso-font-kerning:8.0pt;}

p.MsoBlockText, li.MsoBlockText, div.MsoBlockText

        {margin-top:0in;

        margin-right:1.0in;

        margin-bottom:6.0pt;

        margin-left:1.0in;

        mso-pagination:widow-orphan;

        font-size:10.0pt;

        mso-bidi-font-size:12.0pt;

        font-family:Arial;

        mso-fareast-font-family:"Times New Roman";

        mso-bidi-font-family:"Times New Roman";}

a:link, span.MsoHyperlink

        {color:blue;

        text-decoration:underline;

        text-underline:single;}

a:visited, span.MsoHyperlinkFollowed

        {color:purple;

        text-decoration:underline;

        text-underline:single;}

p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig

        {margin:0in;

        margin-bottom:.0001pt;

        mso-pagination:widow-orphan;

        font-size:10.0pt;

        mso-bidi-font-size:12.0pt;

        font-family:Arial;

        mso-fareast-font-family:"Times New Roman";

        mso-bidi-font-family:"Times New Roman";}

span.EmailStyle15

        {mso-style-type:personal-compose;

        mso-ansi-font-size:10.0pt;

        mso-ascii-font-family:Tahoma;

        mso-hansi-font-family:Tahoma;

        mso-bidi-font-family:Arial;

        color:#333399;

        font-weight:normal;

        font-style:normal;}

p.PictureFrame, li.PictureFrame, div.PictureFrame

        {mso-style-name:PictureFrame;

        mso-style-parent:"Body Text";

        margin-top:6.0pt;

        margin-right:0in;

        margin-bottom:3.0pt;

        margin-left:0in;

        text-align:center;

        mso-line-height-alt:10.0pt;

        mso-pagination:widow-orphan;

        mso-element:frame;

        mso-element-frame-width:155.95pt;

        mso-element-frame-hspace:9.05pt;

        mso-element-wrap:auto;

        mso-element-anchor-vertical:paragraph;

        mso-element-anchor-horizontal:page;

        mso-element-left:48.2pt;

        mso-element-top:.05pt;

        mso-height-rule:exactly;

        font-size:10.5pt;

        mso-bidi-font-size:10.0pt;

        font-family:Garamond;

        mso-fareast-font-family:"Times New Roman";

        mso-bidi-font-family:"Times New Roman";

        color:black;

        mso-font-kerning:8.0pt;}

p.CaptionUpper, li.CaptionUpper, div.CaptionUpper

        {mso-style-name:"Caption Upper";

        mso-style-update:auto;

        mso-style-parent:Caption;

        margin-top:3.0pt;

        margin-right:0in;

        margin-bottom:0in;

        margin-left:0in;

        margin-bottom:.0001pt;

        mso-pagination:widow-orphan;

        page-break-after:avoid;

        mso-list:skip;

        font-size:11.0pt;

        mso-bidi-font-size:10.0pt;

        font-family:"Bookman Old Style";

        mso-fareast-font-family:"Times New Roman";

        mso-bidi-font-family:"Times New Roman";

        color:black;

        letter-spacing:-.4pt;

        mso-font-kerning:8.0pt;

        mso-bidi-font-weight:bold;

        font-style:italic;

        mso-bidi-font-style:normal;}

p.EvenPageHeader, li.EvenPageHeader, div.EvenPageHeader

        {mso-style-name:"Even Page Header";

        mso-style-update:auto;

        mso-style-parent:Header;

        margin-top:3.0pt;

        margin-right:-.55pt;

        margin-bottom:3.0pt;

        margin-left:0in;

        text-align:center;

        mso-pagination:widow-orphan;

        mso-hyphenate:none;

        tab-stops:center 3.0in right 6.0in;

        border:none;

        mso-border-bottom-alt:solid #999999 3.0pt;

        padding:0in;

        mso-padding-alt:0in 0in 1.0pt 0in;

        font-size:14.0pt;

        mso-bidi-font-size:12.0pt;

        font-family:"Arial Narrow";

        mso-fareast-font-family:"Times New Roman";

        mso-bidi-font-family:Arial;

        font-variant:small-caps;

        color:gray;

        mso-bidi-font-weight:bold;}

p.FirstPageHeader, li.FirstPageHeader, div.FirstPageHeader

        {mso-style-name:"First Page Header";

        mso-style-update:auto;

        mso-style-parent:Header;

        margin-top:3.0pt;

        margin-right:-.55pt;

        margin-bottom:3.0pt;

        margin-left:0in;

        text-align:center;

        mso-pagination:widow-orphan;

        mso-hyphenate:none;

        tab-stops:center 3.0in right 6.0in;

        border:none;

        mso-border-top-alt:solid windowtext .5pt;

        padding:0in;

        mso-padding-alt:1.0pt 0in 0in 0in;

        font-size:10.0pt;

        mso-bidi-font-size:12.0pt;

        font-family:Arial;

        mso-fareast-font-family:"Times New Roman";

        display:none;

        mso-hide:all;}

p.OddPageHeader, li.OddPageHeader, div.OddPageHeader

        {mso-style-name:"Odd Page Header";

        mso-style-update:auto;

        mso-style-parent:Header;

        margin-top:3.0pt;

        margin-right:-.55pt;

        margin-bottom:3.0pt;

        margin-left:0in;

        text-align:center;

        mso-pagination:widow-orphan;

        mso-hyphenate:none;

        tab-stops:center 3.0in right 6.0in;

        border:none;

        mso-border-bottom-alt:solid #999999 3.0pt;

        padding:0in;

        mso-padding-alt:0in 0in 1.0pt 0in;

        font-size:14.0pt;

        mso-bidi-font-size:12.0pt;

        font-family:"Arial Narrow";

        mso-fareast-font-family:"Times New Roman";

        mso-bidi-font-family:Arial;

        font-variant:small-caps;

        color:gray;}

p.Subhead, li.Subhead, div.Subhead

        {mso-style-name:Subhead;

        mso-style-update:auto;

        mso-style-parent:"Body Text";

        mso-style-next:"Body Text";

        margin-top:3.0pt;

        margin-right:0in;

        margin-bottom:0in;

        margin-left:.25in;

        margin-bottom:.0001pt;

        text-align:justify;

        text-indent:-.25in;

        line-height:10.0pt;

        mso-pagination:widow-orphan;

        mso-list:skip;

        font-size:10.0pt;

        font-family:Palatino;

        mso-fareast-font-family:"Times New Roman";

        mso-bidi-font-family:"Times New Roman";

        color:black;

        mso-font-kerning:8.0pt;

        font-weight:bold;

        mso-bidi-font-weight:normal;}

@page Section1

        {size:8.5in 11.0in;

        margin:1.0in 1.25in 1.0in 1.25in;

        mso-header-margin:.5in;

        mso-footer-margin:.5in;

        mso-paper-source:0;}

div.Section1

        {page:Section1;}

 /* List Definitions */

@list l0

        {mso-list-id:-125;

        mso-list-type:simple;

        mso-list-template-ids:1699902022;}

@list l0:level1

        {mso-level-number-format:bullet;

        mso-level-text:\F0B7;

        mso-level-tab-stop:.5in;

        mso-level-number-position:left;

        text-indent:-.25in;

        font-family:Symbol;}

@list l1

        {mso-list-id:-120;

        mso-list-type:simple;

        mso-list-template-ids:1095377686;}

@list l1:level1

        {mso-level-style-link:"List Number";

        mso-level-tab-stop:.25in;

        mso-level-number-position:left;

        margin-left:.25in;

        text-indent:-.25in;}

@list l2

        {mso-list-id:-119;

        mso-list-type:simple;

        mso-list-template-ids:-217261656;}

@list l2:level1

        {mso-level-number-format:bullet;

        mso-level-text:\F0B7;

        mso-level-tab-stop:.25in;

        mso-level-number-position:left;

        margin-left:.25in;

        text-indent:-.25in;

        font-family:Symbol;}

@list l3

        {mso-list-id:35391595;

        mso-list-type:hybrid;

        mso-list-template-ids:1081115998 -2084428984 67698691 67698693 67698689 =

67698691 67698693 67698689 67698691 67698693;}

@list l3:level1

        {mso-level-number-format:bullet;

        mso-level-text:\F0B7;

        mso-level-tab-stop:.5in;

        mso-level-number-position:left;

        text-indent:-.25in;

        font-family:Symbol;}

@list l4

        {mso-list-id:90012388;

        mso-list-type:hybrid;

        mso-list-template-ids:-1374913954 1909592616 67698691 67698693 67698689 =

67698691 67698693 67698689 67698691 67698693;}

@list l4:level1

        {mso-level-number-format:bullet;

        mso-level-style-link:"List Bullet";

        mso-level-text:\F0B7;

        mso-level-tab-stop:.5in;

        mso-level-number-position:left;

        text-indent:-.25in;

        font-family:Symbol;}

@list l5

        {mso-list-id:264769342;

        mso-list-type:hybrid;

        mso-list-template-ids:1508023568 524992764 67698713 67698715 67698703 =

67698713 67698715 67698703 67698713 67698715;}

@list l5:level1

        {mso-level-tab-stop:.5in;

        mso-level-number-position:right;

        text-indent:-.25in;}

@list l6

        {mso-list-id:885919098;

        mso-list-type:hybrid;

        mso-list-template-ids:-70112640 1093438490 67698691 67698693 67698689 =

67698691 67698693 67698689 67698691 67698693;}

@list l6:level1

        {mso-level-number-format:bullet;

        mso-level-text:\F0B7;

        mso-level-tab-stop:.75in;

        mso-level-number-position:left;

        margin-left:.75in;

        text-indent:-.25in;

        font-family:Symbol;}

@list l7

        {mso-list-id:902521345;

        mso-list-type:hybrid;

        mso-list-template-ids:679097532 761805272 67698713 67698715 67698703 =

67698713 67698715 67698703 67698713 67698715;}

@list l7:level1

        {mso-level-tab-stop:1.0in;

        mso-level-number-position:left;

        margin-left:1.0in;

        text-indent:-.25in;}

@list l8

        {mso-list-id:905146098;

        mso-list-type:hybrid;

        mso-list-template-ids:609021394 -1880217436 67698691 67698693 67698689 =

67698691 67698693 67698689 67698691 67698693;}

@list l8:level1

        {mso-level-number-format:bullet;

        mso-level-text:\F0B7;

        mso-level-tab-stop:.5in;

        mso-level-number-position:left;

        text-indent:-.25in;

        font-family:Symbol;}

@list l9

        {mso-list-id:1539076883;

        mso-list-type:hybrid;

        mso-list-template-ids:1185023112 2088659148 67698691 67698693 67698689 =

67698691 67698693 67698689 67698691 67698693;}

@list l9:level1

        {mso-level-number-format:bullet;

        mso-level-style-link:"List Bullet 2";

        mso-level-text:\F0B7;

        mso-level-tab-stop:.75in;

        mso-level-number-position:left;

        margin-left:.75in;

        text-indent:-.25in;

        font-family:Symbol;}

ol

        {margin-bottom:0in;}

ul

        {margin-bottom:0in;}

-->

</style>

</head>

 

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =

style=3D'tab-interval:.5in'>

 

<div class=3DSection1>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><span

class=3DEmailStyle15><font size=3D2 color=3D"#333399" =

face=3DTahoma><span

style=3D'font-size:10.0pt;font-family:Tahoma;mso-bidi-font-family:Arial'>=

<span

style=3D'mso-bidi-font-size:12.0pt'>Dear =

Sunil:<o:p></o:p></span></span></font></span></p>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><span

class=3DEmailStyle15><font size=3D2 color=3D"#333399" =

face=3DTahoma><span

style=3D'font-size:10.0pt;font-family:Tahoma;mso-bidi-font-family:Arial'>=

<![if =

!supportEmptyParas]>&nbsp;<![endif]></span><o:p></o:p></font></span></p>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><span

class=3DEmailStyle15><font size=3D2 color=3D"#333399" =

face=3DTahoma><span

style=3D'font-size:10.0pt;font-family:Tahoma;mso-bidi-font-family:Arial'>=

<span

style=3D'mso-bidi-font-size:12.0pt'>Please send me this separately, when =

the last

edits are in, as a WinWord or PDF, I was not able to decode your MIME

attachment. <o:p></o:p></span></span></font></span></p>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><span

class=3DEmailStyle15><font size=3D2 color=3D"#333399" =

face=3DTahoma><span

style=3D'font-size:10.0pt;font-family:Tahoma;mso-bidi-font-family:Arial'>=

<![if =

!supportEmptyParas]>&nbsp;<![endif]></span><o:p></o:p></font></span></p>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><span

class=3DEmailStyle15><font size=3D2 color=3D"#333399" =

face=3DTahoma><span

style=3D'font-size:10.0pt;font-family:Tahoma;mso-bidi-font-family:Arial'>=

<span

style=3D'mso-bidi-font-size:12.0pt'>Do I assume correctly that you want =

this on

the Public side of the web site? I will place it on the Members Only =

side as

well.<o:p></o:p></span></span></font></span></p>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><span

class=3DEmailStyle15><font size=3D2 color=3D"#333399" =

face=3DTahoma><span

style=3D'font-size:10.0pt;font-family:Tahoma;mso-bidi-font-family:Arial'>=

<![if =

!supportEmptyParas]>&nbsp;<![endif]></span><o:p></o:p></font></span></p>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><span

class=3DEmailStyle15><font size=3D2 color=3D"#333399" =

face=3DTahoma><span

style=3D'font-size:10.0pt;font-family:Tahoma;mso-bidi-font-family:Arial'>=

<span

style=3D'mso-bidi-font-size:12.0pt'>Thanks<o:p></o:p></span></span></font=

></span></p>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><span

class=3DEmailStyle15><font size=3D2 color=3D"#333399" =

face=3DTahoma><span

style=3D'font-size:10.0pt;font-family:Tahoma;mso-bidi-font-family:Arial'>=

<![if =

!supportEmptyParas]>&nbsp;<![endif]></span><o:p></o:p></font></span></p>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><span

class=3DEmailStyle15><font size=3D2 color=3D"#333399" =

face=3DTahoma><span

style=3D'font-size:10.0pt;font-family:Tahoma;mso-bidi-font-family:Arial'>=

<span

style=3D'mso-bidi-font-size:12.0pt'>L-)</span></span></font></span><font

color=3D"#333399" face=3D"Courier New"><span =

style=3D'mso-bidi-font-size:10.0pt;

font-family:"Courier =

New";color:#333399;mso-color-alt:windowtext'><o:p></o:p></span></font></p=

>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><font

size=3D2 color=3D"#333399" face=3D"Courier New"><span =

style=3D'font-size:10.0pt;

mso-bidi-font-size:10.0pt;font-family:"Courier New";color:#333399'><![if =

!supportEmptyParas]>&nbsp;<![endif]></span></font><font

color=3D"#333399" face=3D"Courier New"><span =

style=3D'mso-bidi-font-size:10.0pt;

font-family:"Courier =

New";color:#333399;mso-color-alt:windowtext'><o:p></o:p></span></font></p=

>

 

<p class=3DMsoNormal><b><font size=3D1 color=3D"#333399" =

face=3DTahoma><span

style=3D'font-size:9.0pt;mso-bidi-font-size:12.0pt;font-family:Tahoma;col=

or:#333399;

font-weight:bold'>Layna Fischer, General =

Manager</span></font></b><b><font

size=3D1 color=3D"#333399" face=3DTahoma><span =

style=3D'font-size:9.0pt;mso-bidi-font-size:

12.0pt;font-family:Tahoma;color:#333399;mso-color-alt:windowtext;font-wei=

ght:

bold'><o:p></o:p></span></font></b></p>

 

<p class=3DMsoNormal><b><font size=3D1 color=3Dmaroon =

face=3DTahoma><span

style=3D'font-size:9.0pt;mso-bidi-font-size:12.0pt;font-family:Tahoma;col=

or:maroon;

font-weight:bold'>Workflow Management Coalition (W<i><span =

style=3D'font-style:

italic'>f </span></i>MC</span></font></b><b><font size=3D1 =

color=3D"#333399"

face=3DTahoma><span =

style=3D'font-size:9.0pt;mso-bidi-font-size:12.0pt;font-family:

Tahoma;color:#333399;font-weight:bold'>)</span></font></b><font size=3D1

color=3D"#333399" face=3DTahoma><span =

style=3D'font-size:9.0pt;mso-bidi-font-size:

12.0pt;font-family:Tahoma;color:#333399;mso-color-alt:windowtext'><o:p></=

o:p></span></font></p>

 

<p class=3DMsoNormal><font size=3D1 color=3D"#333399" =

face=3DTahoma><span

style=3D'font-size:9.0pt;mso-bidi-font-size:12.0pt;font-family:Tahoma;col=

or:#333399'>2436

North Federal Highway #374, Lighthouse Point, FL 33064, =

USA</span></font><font

size=3D1 color=3D"#333399" face=3DTahoma><span =

style=3D'font-size:9.0pt;mso-bidi-font-size:

12.0pt;font-family:Tahoma;color:#333399;mso-color-alt:windowtext'><o:p></=

o:p></span></font></p>

 

<p class=3DMsoNormal><font size=3D1 color=3D"#333399" =

face=3DTahoma><span

style=3D'font-size:9.0pt;mso-bidi-font-size:12.0pt;font-family:Tahoma;col=

or:#333399'>Phone

+1 954 782 3376, Fax +1 954 782 6365</span></font><font size=3D1 =

color=3D"#333399"

face=3DTahoma><span =

style=3D'font-size:9.0pt;mso-bidi-font-size:12.0pt;font-family:

Tahoma;color:#333399;mso-color-alt:windowtext'><o:p></o:p></span></font><=

/p>

 

<p class=3DMsoNormal><font size=3D1 color=3D"#333399" =

face=3DTahoma><span

style=3D'font-size:9.0pt;mso-bidi-font-size:12.0pt;font-family:Tahoma;col=

or:#333399'>email:

<a href=3D"layna@wfmc.org">layna@wfmc.org</a><span =

style=3D"mso-spacerun:

yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=

bsp;

</span><a =

href=3D"http://www.wfmc.org/">http://www.wfmc.org/</a></span></font><font=

 

color=3D"#333399"><span =

style=3D'color:#333399;mso-color-alt:windowtext'><o:p></o:p></span></font=

></p>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><font

size=3D2 color=3D"#333399" face=3D"Courier New"><span =

style=3D'font-size:10.0pt;

mso-bidi-font-size:10.0pt;font-family:"Courier New";color:#333399'><![if =

!supportEmptyParas]>&nbsp;<![endif]></span></font><font

color=3D"#333399" face=3D"Courier New"><span =

style=3D'mso-bidi-font-size:10.0pt;

font-family:"Courier =

New";color:#333399;mso-color-alt:windowtext'><o:p></o:p></span></font></p=

>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><font

size=3D2 color=3D"#333399" face=3D"Courier New"><span =

style=3D'font-size:10.0pt;

mso-bidi-font-size:10.0pt;font-family:"Courier New";color:#333399'><![if =

!supportEmptyParas]>&nbsp;<![endif]></span></font><font

color=3D"#333399" face=3D"Courier New"><span =

style=3D'mso-bidi-font-size:10.0pt;

font-family:"Courier =

New";color:#333399;mso-color-alt:windowtext'><o:p></o:p></span></font></p=

>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><font

size=3D2 color=3D"#333399" face=3D"Courier New"><span =

style=3D'font-size:10.0pt;

mso-bidi-font-size:10.0pt;font-family:"Courier =

New";color:#333399'>NextPart_000_016B_01BF98BD.98220330</span></font><fon=

t

color=3D"#333399" face=3D"Courier New"><span =

style=3D'mso-bidi-font-size:10.0pt;

font-family:"Courier =

New";color:#333399;mso-color-alt:windowtext'><o:p></o:p></span></font></p=

>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><font

size=3D2 color=3D"#333399" face=3D"Courier New"><span =

style=3D'font-size:10.0pt;

mso-bidi-font-size:10.0pt;font-family:"Courier =

New";color:#333399'>Content-Type:

text/plain;</span></font><font color=3D"#333399" face=3D"Courier =

New"><span

style=3D'mso-bidi-font-size:10.0pt;font-family:"Courier =

New";color:#333399;

mso-color-alt:windowtext'><o:p></o:p></span></font></p>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><font

size=3D2 color=3D"#333399" face=3D"Courier New"><span =

style=3D'font-size:10.0pt;

mso-bidi-font-size:10.0pt;font-family:"Courier New";color:#333399'><span

style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

</span>charset=3D&quot;iso-8859-1&quot;</span></font><font =

color=3D"#333399"

face=3D"Courier New"><span =

style=3D'mso-bidi-font-size:10.0pt;font-family:"Courier New";

color:#333399;mso-color-alt:windowtext'><o:p></o:p></span></font></p>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><font

size=3D2 color=3D"#333399" face=3D"Courier New"><span =

style=3D'font-size:10.0pt;

mso-bidi-font-size:10.0pt;font-family:"Courier =

New";color:#333399'>Content-Transfer-Encoding:

7bit</span></font><font color=3D"#333399" face=3D"Courier New"><span

style=3D'mso-bidi-font-size:10.0pt;font-family:"Courier =

New";color:#333399;

mso-color-alt:windowtext'><o:p></o:p></span></font></p>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><font

size=3D2 color=3D"#333399" face=3D"Courier New"><span =

style=3D'font-size:10.0pt;

mso-bidi-font-size:10.0pt;font-family:"Courier New";color:#333399'><![if =

!supportEmptyParas]>&nbsp;<![endif]></span></font><font

color=3D"#333399" face=3D"Courier New"><span =

style=3D'mso-bidi-font-size:10.0pt;

font-family:"Courier =

New";color:#333399;mso-color-alt:windowtext'><o:p></o:p></span></font></p=

>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><font

size=3D2 color=3D"#333399" face=3D"Courier New"><span =

style=3D'font-size:10.0pt;

mso-bidi-font-size:10.0pt;font-family:"Courier =

New";color:#333399'>Enclosed is

a close to final version of the paper that we (Hayes, =

Peyrovian,</span></font><font

color=3D"#333399" face=3D"Courier New"><span =

style=3D'mso-bidi-font-size:10.0pt;

font-family:"Courier =

New";color:#333399;mso-color-alt:windowtext'><o:p></o:p></span></font></p=

>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><font

size=3D2 color=3D"#333399" face=3D"Courier New"><span =

style=3D'font-size:10.0pt;

mso-bidi-font-size:10.0pt;font-family:"Courier =

New";color:#333399'>Sarin,

Schmidt, Swenson, Weber) sent to the publishers; they will be =

doing</span></font><font

color=3D"#333399" face=3D"Courier New"><span =

style=3D'mso-bidi-font-size:10.0pt;

font-family:"Courier =

New";color:#333399;mso-color-alt:windowtext'><o:p></o:p></span></font></p=

>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><font

size=3D2 color=3D"#333399" face=3D"Courier New"><span =

style=3D'font-size:10.0pt;

mso-bidi-font-size:10.0pt;font-family:"Courier New";color:#333399'>some =

cleanup

and editing before it appears in the May/June issue.<span =

style=3D"mso-spacerun:

yes">&nbsp; </span>If anyone</span></font><font color=3D"#333399"

face=3D"Courier New"><span =

style=3D'mso-bidi-font-size:10.0pt;font-family:"Courier New";

color:#333399;mso-color-alt:windowtext'><o:p></o:p></span></font></p>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><font

size=3D2 color=3D"#333399" face=3D"Courier New"><span =

style=3D'font-size:10.0pt;

mso-bidi-font-size:10.0pt;font-family:"Courier New";color:#333399'>has =

any

last-minute factual corrections, including giving =

appropriate</span></font><font

color=3D"#333399" face=3D"Courier New"><span =

style=3D'mso-bidi-font-size:10.0pt;

font-family:"Courier =

New";color:#333399;mso-color-alt:windowtext'><o:p></o:p></span></font></p=

>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><font

size=3D2 color=3D"#333399" face=3D"Courier New"><span =

style=3D'font-size:10.0pt;

mso-bidi-font-size:10.0pt;font-family:"Courier =

New";color:#333399'>credit,

please let me know.</span></font><font color=3D"#333399" face=3D"Courier =

New"><span

style=3D'mso-bidi-font-size:10.0pt;font-family:"Courier =

New";color:#333399;

mso-color-alt:windowtext'><o:p></o:p></span></font></p>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><font

size=3D2 color=3D"#333399" face=3D"Courier New"><span =

style=3D'font-size:10.0pt;

mso-bidi-font-size:10.0pt;font-family:"Courier New";color:#333399'><![if =

!supportEmptyParas]>&nbsp;<![endif]></span></font><font

color=3D"#333399" face=3D"Courier New"><span =

style=3D'mso-bidi-font-size:10.0pt;

font-family:"Courier =

New";color:#333399;mso-color-alt:windowtext'><o:p></o:p></span></font></p=

>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><font

size=3D2 color=3D"#333399" face=3D"Courier New"><span =

style=3D'font-size:10.0pt;

mso-bidi-font-size:10.0pt;font-family:"Courier New";color:#333399'>If =

the

Secretariat is watching, can you put this up on the Web =

site?</span></font><font

color=3D"#333399" face=3D"Courier New"><span =

style=3D'mso-bidi-font-size:10.0pt;

font-family:"Courier =

New";color:#333399;mso-color-alt:windowtext'><o:p></o:p></span></font></p=

>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><font

size=3D2 color=3D"#333399" face=3D"Courier New"><span =

style=3D'font-size:10.0pt;

mso-bidi-font-size:10.0pt;font-family:"Courier =

New";color:#333399'>Thanks,</span></font><font

color=3D"#333399" face=3D"Courier New"><span =

style=3D'mso-bidi-font-size:10.0pt;

font-family:"Courier =

New";color:#333399;mso-color-alt:windowtext'><o:p></o:p></span></font></p=

>

 

<p class=3DMsoNormal =

style=3D'mso-layout-grid-align:none;text-autospace:none'><font

size=3D2 color=3D"#333399" face=3D"Courier New"><span =

style=3D'font-size:10.0pt;

mso-bidi-font-size:10.0pt;font-family:"Courier New";color:#333399'><span

style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp; =

</span>Sunil</span></font><font

color=3D"#333399" face=3D"Courier New"><span =

style=3D'mso-bidi-font-size:10.0pt;

font-family:"Courier =

New";color:#333399;mso-color-alt:windowtext'><o:p></o:p></span></font></p=

>

 

<p class=3DMsoNormal><span class=3DEmailStyle15><font size=3D2 =

color=3D"#333399"

face=3DTahoma><span =

style=3D'font-size:10.0pt;font-family:Tahoma;mso-bidi-font-family:

Arial'><![if =

!supportEmptyParas]>&nbsp;<![endif]></span><o:p></o:p></font></span></p>

 

</div>

 

</body>

 

</html>

 

------=_NextPart_000_0000_01BF9913.E3AC2000--

 

------------------------------

 

Date:    Tue, 28 Mar 2000 23:53:22 -0800

From:    Keith Swenson <kswenson@MS2.COM>

Subject: What needs to be done to finish Wf-XML 1.0?  Conference Call.

 

This message is in MIME format. Since your mail reader does not understand

this format, some or all of this message may not be legible.

 

------_=_NextPart_001_01BF9953.DBA87990

Content-Type: text/plain;

        charset="iso-8859-1"

 

This is the question we need to all ask ourselves: "What needs to be done in

order to approve Wf-XML for distribution."  We must finish this, before we

can get on to the more important tasks of extending the spec in the ways

that we know people are demanding.  This of course will be the subject of

the conference call.  Below have tried to collect together the issues

together with my own responses.

 

**1** From Peter Wedekind, March 14

>  Without the information about the new state of the instance...

 

I believe that the value of the "state" tag contains the new state, doesn't

it?  Maybe I don't understand the issue...

 

**2** From Rainer Weber, March 17

>  URLs and Keys ... all of these problems would be solved, if

> I could store the business partner address separately from the key.

 

I agree that there is an issue to be resolved -- this is part of my

motivation for proposing the WfEnvelope for the future direction.  I believe

that the solution is that the WfMessage carries a "relative URI" when

needed, and in these cases the scope is found in the envelope.  Since a

"relative URI" still conforms to URI standards for encoding data, the

existing definition that the key is a URI should stand -- it does not

exclude the possibility of the use above.  I believe that tying the data

format of Key to a public standard is far more valuable than leaving Key to

be "vendor specific strings".  The spec of a URI tells what characters are

allowed, and how to encode characters outside that set, etc.

 

**3** From Rainer Weber, March 17

>  Proposal: Interoperability test before standard appears.

 

This is always the dilemma.  Doing imiplementation before releasing spec

would validate the spec.  Releasing the spec will encourage people to start

implementations.  I would decide like this: WfMC is an organization that is

empowered to release specs.  WfMC can not make implementations.  Tying an

internal goal to an external deliverable is bound to fail.  Let's release it

and incorporate what we learn in 2.0.

 

**4** From Rainer Weber, March 17

>  Repetition of "Key"

 

I agree we should have only one.  I believe it should be in the header since

the only point of the header is to hold those things that are common to all

operations.  The key qualifies in this.  (Why define this for every

operation when it could be defined only once in the header?)

 

**5** From Rainer Weber, March 17

>  recommend to put the Exception into

> the body as a possible "result" (remove it from the header).

 

I am indifferent on this, except again, why must exception be defined

separately for every single response when it could be defined once in the

header?

 

**6** From Michael Rossi, March 20:

> My two most pressing points involve the use of attributes where

> appropriate.

 

You have made a well considered argument for ReponseRequired &

StartImmediately to be attributes.  I had not previously held strong

feelings either way on this, but I am persuaded that you have a good point

in these two cases.  We should make this change.

 

**7** From Michael Rossi, March 20:

> "Notification" should be a first-class message

> type, just like Request and Response.

 

I disagree.  A 'request' is a call from one resource/object to another done

on the initiative of the first resource.  This is no different from a

'notification'. In the OMG workflow, the notification is a method call, just

like all the other method calls.  The request/response pattern is the build

block of the next level of semantics, which is what differentiates one

method from another.  And besides, responses are not always required.

Rainer's message covers this in sufficient detail.

 

I further am opposed to such a deep structural change that has not had

significant throught within the group at this time.

 

**8** From Nobuyuki Kanaya, March 20:

> NEC and Fujitsu proposed some extensions that include functions of not

> only making batch and asynchronous requests but also controlling and

> referring requests.

 

I have a version of this document that was distributed at the December

meeting.  I have heard that there is a new version that is consistent with

the current Wf-XML proposal.  I would like very much to get a copy of this.

Could you send it to the list?

 

**9** From Nobuyuki Kanaya, March 20:

> Asynchronous batch requests are not issues of transport layer.

 

You make many good points here.  As you know, it is very difficult to

clearly and uambiguously divide system functionality into discrete levels.

A guideline that I use to decide what goes where is: if the information is

about workflow (e.g. actors, context data, activities, processes, etc.) it

belongs in the message; if the information is about finding things,

connecting to things, confirming things, and guarding information it belongs

in the transport layer.  These things in the transport layer are not unique

to workflow in any way -- they are just as applicable to any other type of

distributed application.  The chief reason I draw this distinction is that I

know that other solutions already exists in those areas, and we need to be

positioned to cooperate as much as possible with other standards.  I realize

that this means some of the things in v1.0 include some transport concepts.

That is OK, we can address this in v2.0.

 

**10** From Nobuyuki Kanaya, March 20:

> How do you change formats of WfHeader naturally?   Some

> elements of <WfMessageHeader>(e.g. <sessionID>, <from>, and <to>)

> must move to WfEnvelope ...

 

The tags 'sessionID', 'from', and 'to' are not part of WfMessageHeader in

Wf-XML v1.0 so this is still work for 2.0.

 

**11** From Michael Rossi, March 21:

> If we want to do away with the concept of notifications, that's OK.

> But then this operation should go away in lieu of simply sending a

> response to ChangeProcessInstanceState.

 

No, lets not remove this operation.  This pattern is well established in the

OMG standard.  The process instance can only return a response to

ChangeProcessInstanceState at the time that a request is made.  The whole

point of ProcessInstaceStateChanged is that it is communicated on the

initiative of the process instance.  What you suggest would not work.

 

**12** From the document delivered March 28

> The namespace id is:  http: //www.wfmc.org/standards/docs/Wf-XML

 

I always find it amusing that people seem to think that an organization will

produce hundreds or thousands of namespaces, and so such long identifiers

are used.  It would be quite sufficient to use "http: //www.wfmc.org/1" --

whenever we develop another namespace, it can be called "http:

//www.wfmc.org/2".  There are, after all, an infinite number of such names

to be given out, so they could be liberally handed out to working groups.

Ok, this is not important, I will go along with any identifier chosen.  :-)

 

**13** From the document delivered March 28

Date and time mentions "GMT".  I thought this was supposed to be changed to

"UTC".

 

**14** From Michael Rossi, March 20:

> With regard to things such as "envelopes" ... W3C claims to be

> establishing a working group to investigate what they've termed

> "XML Packaging".

 

It is important to keep the envelope proposal separate from the message

format for exactly this reason: there are numerous such technologies which

we may wish to make use of.  My proposal for a WfEnvelope is not meant to be

chosen instead of those options, but rather only in those cases where no

existing envelope capability exists.  We certainly should investigate this

W3C work, so thanks for bringing it up.

 

-Keith

 

----------------------------------------------------------------

Keith D. Swenson, kswenson@ms2.com, MS2 Inc.

2440 W. El Camino Real, Mountain View, CA, 94040

tel: +1 650 623-2329,  fax: +1 650 967-7394

 

 

 

------_=_NextPart_001_01BF9953.DBA87990

Content-Type: text/html;

        charset="iso-8859-1"

Content-Transfer-Encoding: quoted-printable

 

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">

<HTML>

<HEAD>

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =

charset=3Diso-8859-1">

<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =

5.5.2650.12">

<TITLE>What needs to be done to finish Wf-XML 1.0?  Conference =

Call.</TITLE>

</HEAD>

<BODY>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">This is the question we need to all =

ask ourselves: &quot;What needs to be done in order to approve Wf-XML =

for distribution.&quot;&nbsp; We must finish this, before we can get on =

to the more important tasks of extending the spec in the ways that we =

know people are demanding.&nbsp; This of course will be the subject of =

the conference call.&nbsp; Below have tried to collect together the =

issues together with my own responses.</FONT></P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">**1** From Peter Wedekind, March =

14</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;</FONT> <FONT SIZE=3D2 =

FACE=3D"Courier New">Without the information about the new state of the =

instance...</FONT>

</P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">I believe that the value of the =

&quot;state&quot; tag contains the new state</FONT><FONT SIZE=3D2 =

FACE=3D"Courier New">, doesn't it?&nbsp; Maybe I don't understand the =

issue...</FONT>

</P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">**2** From Rainer Weber, March =

17</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;</FONT> <FONT SIZE=3D2 =

FACE=3D"Courier New">URLs and Keys ... all of these problems would be =

solved, if</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; I could store the business =

partner address separately from the key.</FONT>

</P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">I agree that there is an issue to be =

resolved -- this is part of my motivation for proposing the WfEnvelope =

for the future direction.&nbsp; I believe that the solution is that the =

WfMessage carries a &quot;relative URI&quot; when needed, and in these =

cases the scope is found in the envelope.&nbsp; Since a &quot;relative =

URI&quot; still conforms to URI standards for encoding data, the =

existing definition that the key is a URI should stand -- it does not =

exclude the possibility of the use above.&nbsp; I believe that tying =

the data format of Key to a public standard is far more valuable than =

leaving Key to be &quot;vendor specific strings&quot;.&nbsp; The spec =

of a URI tells what characters are allowed, and how to encode =

characters outside that set, etc.</FONT></P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">**3** From Rainer Weber, March =

17</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;</FONT> <FONT SIZE=3D2 =

FACE=3D"Courier New">Proposal: Interoperability test before standard =

appears.</FONT>

</P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">This is always the dilemma.&nbsp; =

Doing imiplementation before releasing spec would validate the =

spec.&nbsp; Releasing the spec will encourage people to start =

implementations.&nbsp; I would decide like this: WfMC is an =

organization that is empowered to release specs.&nbsp; WfMC can not =

make implementations.&nbsp; Tying an internal goal to an external =

deliverable is bound to fail.&nbsp; Let's release it and incorporate =

what we learn in 2.0.</FONT></P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">**4** From Rainer Weber, March =

17</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;</FONT> <FONT SIZE=3D2 =

FACE=3D"Courier New">Repetition of &quot;Key&quot;</FONT>

</P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">I agree we should have only one.&nbsp; =

I believe it should be in the header since the only point of the header =

is to hold those things that are common to all operations.&nbsp; The =

key qualifies in this.&nbsp; (Why define this for every operation when =

it could be defined only once in the header?)</FONT></P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">**5** From Rainer Weber, March =

17</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;&nbsp;</FONT> <FONT SIZE=3D2 =

FACE=3D"Courier New">recommend to put the Exception into</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; the body as a possible =

&quot;result&quot; (remove it from the header).</FONT>

</P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">I am indifferent on this, except =

again, why must exception be defined separately for every single =

response when it could be defined once in the header?</FONT></P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">**6** From Michael Rossi, March =

20:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; My two most pressing =

points involve the use of attributes where</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; appropriate.</FONT>

</P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">You have made a well considered =

argument for ReponseRequired &amp; StartImmediately to be =

attributes.&nbsp; I had not previously held strong feelings either way =

on this, but I am persuaded that you have a good point in these two =

cases.&nbsp; We should make this change.</FONT></P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">**7** From Michael Rossi, March =

20:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; &quot;Notification&quot; =

should be a first-class message</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; type, just like Request =

and Response.</FONT>

</P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">I disagree.&nbsp; A 'request' is a =

call from one resource/object to another done on the initiative of the =

first resource.&nbsp; This is no different from a 'notification'. In =

the OMG workflow, the notification is a method call, just like all the =

other method calls.&nbsp; The request/response pattern is the build =

block of the next level of semantics, which is what differentiates one =

method from another.&nbsp; And besides, responses are not always =

required. Rainer's message covers this in sufficient detail.</FONT></P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">I further am opposed to such a deep =

structural change that has not had significant throught within the =

group at this time.&nbsp; </FONT></P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">**8**</FONT> <FONT SIZE=3D2 =

FACE=3D"Arial">From Nobuyuki Kanaya, March 20:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; NEC and Fujitsu proposed =

some extensions that include functions of not</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; only making batch and =

asynchronous requests but also controlling and</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; referring requests. =

</FONT>

</P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">I have a version of this document that =

was distributed at the December meeting.&nbsp; I have heard that there =

is a new version that is consistent with the current Wf-XML =

proposal.&nbsp; I would like very much to get a copy of this.&nbsp; =

Could you send it to the list?</FONT></P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">**9**</FONT> <FONT SIZE=3D2 =

FACE=3D"Arial">From Nobuyuki Kanaya, March 20:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; Asynchronous batch =

requests are not issues of transport layer.</FONT>

</P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">You make many good points here.&nbsp; =

As you know, it is very difficult to clearly and uambiguously divide =

system functionality into discrete levels.&nbsp; A guideline that I use =

to decide what goes where is: if the information is about workflow =

(e.g. actors, context data, activities, processes, etc.) it belongs in =

the message; if the information is about finding things, connecting to =

things, confirming things, and guarding information it belongs in the =

transport layer.&nbsp; These things in the transport layer are not =

unique to workflow in any way -- they are just as applicable to any =

other type of distributed application.&nbsp; The chief reason I draw =

this distinction is that I know that other solutions already exists in =

those areas, and we need to be positioned to cooperate as much as =

possible with other standards.&nbsp; I realize that this means some of =

the things in v1.0 include some transport concepts.&nbsp; That is OK, =

we can address this in v2.0.</FONT></P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">**10**</FONT> <FONT SIZE=3D2 =

FACE=3D"Arial">From Nobuyuki Kanaya, March 20:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT> <FONT SIZE=3D2 =

FACE=3D"Courier New">How do you change formats of WfHeader =

naturally?&nbsp;&nbsp; Some</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; elements of =

&lt;WfMessageHeader&gt;(e.g. &lt;sessionID&gt;, &lt;from&gt;, and =

&lt;to&gt;) </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; must move to WfEnvelope =

...</FONT>

</P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">The tags 'sessionID', 'from', and 'to' =

are not part of WfMessageHeader in Wf-XML v1.0 so this is still work =

for 2.0.</FONT>

</P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">**11** From Michael Rossi, March =

21:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; If we want to do away with =

the concept of notifications, that's OK. </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; But then this operation =

should go away in lieu of simply sending a </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; response to =

ChangeProcessInstanceState.</FONT>

</P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">No, lets not remove this =

operation.&nbsp; This pattern is well established in the OMG =

standard.&nbsp; The process instance can only return a response to =

ChangeProcessInstanceState at the time that a request is made.&nbsp; =

The whole point of ProcessInstaceStateChanged is that it is =

communicated on the initiative of the process instance.&nbsp; What you =

suggest would not work.</FONT></P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">**12** From the document delivered =

March 28</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt; The namespace id is:&nbsp; =

</FONT><FONT COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">h</FONT><FONT =

COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial">ttp:</FONT><FONT =

COLOR=3D"#000000" SIZE=3D2 FACE=3D"Arial"></FONT> <FONT =

COLOR=3D"#000000" SIZE=3D2 =

FACE=3D"Arial">//www.wfmc.org/standards/docs/Wf-XML</FONT>

</P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">I always find it amusing that people =

seem to think that an organization will produce hundreds or thousands =

of namespaces, and so such long identifiers are used.&nbsp; It would be =

quite sufficient to use </FONT><FONT COLOR=3D"#000000" SIZE=3D2 =

FACE=3D"Arial">&quot;http: //www.wfmc.org/1&quot;</FONT><FONT SIZE=3D2 =

FACE=3D"Arial"> -- whenever we develop another namespace, it can be =

called </FONT><FONT COLOR=3D"#000000" SIZE=3D2 =

FACE=3D"Arial">&quot;http: //www.wfmc.org/2&quot;.&nbsp; There are, =

after all, an infinite number of such names to be given out, so they =

could be liberally handed out to working groups.&nbsp; Ok, this is not =

important, I will go along with any identifier chosen.&nbsp; =

:-)</FONT></P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">**13**</FONT> <FONT SIZE=3D2 =

FACE=3D"Arial">From the document delivered March 28</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Date and time mentions =

&quot;GMT&quot;.&nbsp; I thought this was supposed to be changed to =

&quot;UTC&quot;.</FONT>

</P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">**14** From Michael Rossi, March =

20:</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&gt;</FONT> <FONT SIZE=3D2 =

FACE=3D"Courier New">With regard to things such as =

&quot;envelopes&quot; ... W3C claims to be </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; establishing a working =

group to investigate what they've termed </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Courier New">&gt; &quot;XML =

Packaging&quot;.</FONT>

</P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">It is important to keep the envelope =

proposal separate from the message format for exactly this reason: =

there are numerous such technologies which we may wish to make use =

of.&nbsp; My proposal for a WfEnvelope is not meant to be chosen =

instead of those options, but rather only in those cases where no =

existing envelope capability exists.&nbsp; We certainly should =

investigate this W3C work, so thanks for bringing it up.</FONT></P>

 

<P><FONT SIZE=3D2 FACE=3D"Arial">-Keith</FONT>

</P>

 

<P ALIGN=3DCENTER><FONT COLOR=3D"#800000" SIZE=3D2 =

FACE=3D"Arial">---------------------------------------------------------=

-------</FONT></P>

 

<P ALIGN=3DCENTER><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Arial">Keith =

D. Swenson, kswenson@ms2.com, MS2 Inc.</FONT></P>

 

<P ALIGN=3DCENTER><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Arial">2440 =

W. El Camino Real, Mountain View, CA, 94040</FONT></P>

 

<P ALIGN=3DCENTER><FONT COLOR=3D"#800000" SIZE=3D2 FACE=3D"Arial">tel: =

+1 650 623-2329,&nbsp; fax: +1 650 967-7394</FONT></P>

<BR>

 

</BODY>

</HTML>

------_=_NextPart_001_01BF9953.DBA87990--

 

------------------------------

 

Date:    Wed, 29 Mar 2000 12:59:23 -0500

From:    Michael Rossi <mrossi@CRUSHER.JCALS.CSC.COM>

Subject: Impending release of Wf-XML Version 1.0

 

This message is in MIME format. Since your mail reader does not understand

this format, some or all of this message may not be legible.

 

------_=_NextPart_000_01BF99A8.8404C9C8

Content-Type: text/plain;

        charset="iso-8859-1"

 

Dear Working Group,

   Several of us participated in a conference call today to discuss the last

remaining issues with Wf-XML 1.0. Lots of great input was received and we'll

be making some nice changes for the initial release. All final changes

should be completed within the next two weeks, which will give us a

candidate for release by 14 April.

 

   As a part of this schedule, a consession will have to be made to forgoe

an interoperability test period before publication of version 1.0. While it

is felt that this testing would be of great value, there is apparently no

formal history of such action in the WfMC. Furthermore, the Wf-XML 1.0 Beta

was exposed to a very wide audience and many comments were resultantly

incorporated. Therefore, version 1.0 will be published without benefit of

such testing and errata will be produced as necessary.

 

   The purpose of this message is to inform the entire working group of this

decision and provide an opportunity for dissent, as we realize that only a

small group was involved in the decision. So if anyone has strong objections

to this approach, by all means make yourself heard. If there is enough

reason to re-evaluate our decision, further action will be taken to reach

consensus. Otherwise, you've been informed. Thanks.

 

Michael A. Rossi

mrossi@csc.com <mailto:mrossi@csc.com>

856-983-4400 x4911

 

------_=_NextPart_000_01BF99A8.8404C9C8

Content-Type: image/jpeg;

        name="Notebook.jpg"

Content-Transfer-Encoding: base64

Content-Disposition: attachment;

        filename="Notebook.jpg"

Content-ID: <571203717@29032000-3779>

 

/9j/4AAQSkZJRgABAgEASABIAAD/7QSyUGhvdG9zaG9wIDMuMAA4QklNA+kAAAAAAHgAAwAAAEgA

SAAAAAADBgJS//f/9wMPAlsDRwUoA/wAAgAAAEgASAAAAAAC2AIoAAEAAABkAAAAAQADAwMAAAAB

Jw8AAQABAAAAAAAAAAAAAAAAYAgAGQGQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA4

QklNA+0AAAAAABAASAAAAAEAAQBIAAAAAQABOEJJTQPzAAAAAAAIAAAAAAAAAAA4QklNBAoAAAAA

AAEAADhCSU0nEAAAAAAACgABAAAAAAAAAAI4QklNA/UAAAAAAEgAL2ZmAAEAbGZmAAYAAAAAAAEA

L2ZmAAEAoZmaAAYAAAAAAAEAMgAAAAEAWgAAAAYAAAAAAAEANQAAAAEALQAAAAYAAAAAAAE4QklN

A/gAAAAAAHAAAP////////////////////////////8D6AAAAAD/////////////////////////

////A+gAAAAA/////////////////////////////wPoAAAAAP//////////////////////////

//8D6AAAOEJJTQQAAAAAAAACAAA4QklNBAIAAAAAAAIAADhCSU0ECAAAAAAAEAAAAAEAAAJAAAAC

QAAAAAA4QklNBAkAAAAAAqIAAAABAAAAgAAAAAIAAAGAAAADAAAAAoYAGAAB/9j/4AAQSkZJRgAB

AgEASABIAAD//gAnRmlsZSB3cml0dGVuIGJ5IEFkb2JlIFBob3Rvc2hvcKggNC4wAP/uAA5BZG9i

ZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwMDAwMEQwMDAwMDAwM

DAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwMDAwMEREMDAwMDAwR

DAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIAAIAgAMBIgACEQEDEQH/3QAEAAj/xAE/

AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAAAAEAAgMEBQYHCAkK

CxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQVUsFiMzRygtFDByWS

U/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0pbXF1eX1VmZ2hpam

tsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRBUWFxIhMFMoGRFKGx

QiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKzhMPTdePzRpSkhbSV

xNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/APROif0Kv6X81T9L

j+ar/m/5K0F8rJJIfqlJfKySKn6pSXyskkp+qUl8rJJKfqlJfKySSn6pSXyskkp+qUl8rJJKfqlJ

fKySSn//2ThCSU0EBgAAAAAABwABAAAAAQEA//4AJ0ZpbGUgd3JpdHRlbiBieSBBZG9iZSBQaG90

b3Nob3CoIDQuMAD/7gAOQWRvYmUAZIAAAAAB/9sAhAAMCAgNCQ0VDAwVGhQQFBogGxoaGyAiFxcX

FxciEQwMDAwMDBEMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMAQ0NDREOERsRERsUDg4OFBQO

Dg4OFBEMDAwMDBERDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz/wAARCAAYBaAD

ASIAAhEBAxEB/90ABABa/8QBPwAAAQUBAQEBAQEAAAAAAAAAAwABAgQFBgcICQoLAQABBQEBAQEB

AQAAAAAAAAABAAIDBAUGBwgJCgsQAAEEAQMCBAIFBwYIBQMMMwEAAhEDBCESMQVBUWETInGBMgYU

kaGxQiMkFVLBYjM0coLRQwclklPw4fFjczUWorKDJkSTVGRFwqN0NhfSVeJl8rOEw9N14/NGJ5Sk

hbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2N0dXZ3eHl6e3x9fn9xEAAgIBAgQEAwQFBgcHBgU1AQAC

EQMhMRIEQVFhcSITBTKBkRShsUIjwVLR8DMkYuFygpJDUxVjczTxJQYWorKDByY1wtJEk1SjF2RF

VTZ0ZeLys4TD03Xj80aUpIW0lcTU5PSltcXV5fVWZnaGlqa2xtbm9ic3R1dnd4eXp7fH/9oADAMB

AAIRAxEAPwCv0T+n4/8AxrP+qavW15J0U/r+P/xrP+qavWg8eKElsWSHZfXWYe4A+ZUMjIFTJBE/

Fc1kXbg63mJP+amk0uesGqdc19Sup2ZrLmWGQxwLR4B35v8A0V0qKlJJJIqUkkkkpSSSSSlJJJJK

UkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSS

SSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJ

KUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpS

SSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJ

JKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkp

SSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJJJKUkkkkpSSSSSlJJ

JJKUkkkkpSSSSSn/0J9G6oKn04zKKXOdYA6x7d1kOP8Ag/3Hs/MXY/sOl/0hYfCT/wCQavnZJArQ

/S1HTXVN21+weYa7/vqzcroeQ+Q3XcYOn/mbF89pIaJfpboXRK+k1uDQPUsILyONPotZ/JatRfKq

SSX6qSXyqkip+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJ

KfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp

+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6

qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqp

JfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl

8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXy

qkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKq

SSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJ

KfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp

+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn6

qSXyqkkp+qkl8qpJKfqpJfKqSSn6qSXyqkkp+qkl8qpJKfqpJfKqSSn/2Q==

 

------_=_NextPart_000_01BF99A8.8404C9C8--

 

------------------------------

 

End of WORKGROUP4 Digest - 28 Mar 2000 to 29 Mar 2000 (#2000-24)

****************************************************************

There are 7 messages totalling 323 lines in this issue.

 

Topics of the day:

 

  1. Issues with Version 1.0 spec (2)

  2. AW: Issues with Version 1.0 spec

  3. XML formats (2)

  4. FW: Issues with Version 1.0 spec

  5. FW: XTech 2000 XML protocol BOF notes

 

----------------------------------------------------------------------

 

Date:    Thu, 23 Mar 2000 07:51:20 +0000

From:    Rob Allen <rob_allen@UK.SNS.CA>

Subject: Issues with Version 1.0 spec

 

The ERC is keen to take a completed 1.0 version of the spec and establish

wf-XML in the XML world.

This is an important positioning for all of us.

The sooner we can make meaningful announcements the better

 

Rob

 

 

 

*********** REPLY SEPARATOR  ***********

 

On 22/03/00 at 23:33 Hollingsworth David wrote:

 

>I would like to see these issues closed out quickly. (Personally I have a

>mild preference for an attribute based approach and agree that a

>notification message type should be for the observer resource - but early

>resolution is more important in my mind than the detail of the actual

>approach.)

>

>Once a V1.0 is completed I suggest that we lodge this with XML.org with

>appropriate comment about the desire to work with other groups

>a. including other XML data content for application and process relevant

>data within workflow interoperability scenarios (from industry

organisations

>with their own XML DTDs)  and

>b. offering the WfMC XML definitions as an indutsry standard approach to

>defining the objects needed for distributed process management, which

could

>be included within other XML (e.g. vertical industry focussed schemes or

>indeed Govt schemes)

>

>This is in line with discussions in Monterey.  Once we have an accurate

and

>stable V1.0 I believe there could be some excellent opportunities for

>expanding teh potential visibility and use via this type of route.

>We could make such an intiative from the TC, perhaps enlisting additional

>support from the Industry Liaison Chair and  Layna?

>Other ideas or suggestions?

>Rgds, Dave H.

 

 

 

Rob Allen

OPEN IMAGE Systems Inc

1000 Great West Road

Brentford, Middlesex, TW8 9HH

Phone:  +(44) 208 261 4454

Fax        (+44) 208 261 4525

 

OPEN IMAGE 3.0:  Best New Workflow Product 1999

 

------------------------------

 

Date:    Thu, 23 Mar 2000 09:14:42 +0100

From:    "Weber, Rainer" <rainer.weber@SAP.COM>

Subject: AW: Issues with Version 1.0 spec

 

My preferences for the phone conference:

- Date: Any day except Thursday is okay with me.

- Time: The earlier, the better.

 

Best regards,

Rainer Weber

SAP AG

 

> -----Urspr=FCngliche Nachricht-----

> Von:  Michael Rossi [SMTP:mrossi@CRUSHER.JCALS.CSC.COM]

> Gesendet am:  Mittwoch, 22. M=E4rz 2000 20:56

> An:   WORKGROUP4@FTPLIST.AIIM.ORG

> Betreff:      Re: Issues with Version 1.0 spec

>=20

> mts@UK.IBM.COM wrote:

> >

> > It would be great if you could set up a conferCall next week to =

discuss

> the

> > remaining issues.

>=20

>    OK, next week's fairly open for me. Any preferences for a =

day/time?

> I'll

> prepare an issues list and distribute the call details once we're set =

up.

> Thanks.

>=20

> Michael A. Rossi

> mailto:mrossi@csc.com

> 856-983-4400 x4911

 

------------------------------

 

Date:    Thu, 23 Mar 2000 11:33:22 -0600

From:    Michael French <mfrench@ZYCOR.LGC.COM>

Subject: XML formats

 

I have a couple of questions about WfMC XML formats.

 

1. The Wf-XML format uses a regular DTD.

    Do you have any plans to move to an XML Schema definition ?

    (I realize the XML Schema spec is not quite frozen yet).

    (I also realize that for a format that doesn't even use attributes,

    jumping to schemas is a bit of a stretch).

 

    If we were to produce a first pass at an XML Schema binding,

    would you be interested in looking at our work ?

 

2. The Wf-XML format specifies the enactment interfaces

    using an XML message format and transactional semantics.

    Will you be producing an XML binding of the static WPDL ?

 

    Again, if we produced such a beast, would you be interested

    in taking a look at our efforts ?

 

3. (OK, not XML but...)

    Is there any effort to produce Java bindings for the APIs

    which are at present only defined in C ?

 

Regards,

Mike

 

------------------------------

 

Date:    Thu, 23 Mar 2000 17:55:48 -0000

From:    Hollingsworth David <David.Hollingsworth@ICL.COM>

Subject: Re: XML formats

 

1. Schemas were one of the items for discussion in the current proposed

contents for Wf-XML v2 (we are also looking at possible use for attributes

as a final tidy up of v1.0)

2. There is an existing working draft; the idea is to tidy this up and

publish - input gratefully received (via WG1). Longer term to be supported

through work on UML/XML (probably in conjunction with the upcoming OMG

Process Definition RFP)

3. Lots of people ask for this but we've never had resource to develop Java

bindings. I think the starting point would probably not be the C spec, but

the IDL in the Joint flow spec.

Rgds, Dave H

 

Dave Hollingsworth

* ICL, Forest Road, Feltham, Middx, TW13 7EJ

* Tel: (+44) 181 730 4112

* Fax: (+44) 181 730 4151

* Mobile: 07867 831803

* E-mail: david.hollingsworth@icl.com

 

 

 

-----Original Message-----

From: Michael French [mailto:mfrench@ZYCOR.LGC.COM]

Sent: 23 March 2000 17:33

To: WORKGROUP4@FTPLIST.AIIM.ORG

Subject: XML formats

 

 

I have a couple of questions about WfMC XML formats.

 

1. The Wf-XML format uses a regular DTD.

    Do you have any plans to move to an XML Schema definition ?

    (I realize the XML Schema spec is not quite frozen yet).

    (I also realize that for a format that doesn't even use attributes,

    jumping to schemas is a bit of a stretch).

 

    If we were to produce a first pass at an XML Schema binding,

    would you be interested in looking at our work ?

 

2. The Wf-XML format specifies the enactment interfaces

    using an XML message format and transactional semantics.

    Will you be producing an XML binding of the static WPDL ?

 

    Again, if we produced such a beast, would you be interested

    in taking a look at our efforts ?

 

3. (OK, not XML but...)

    Is there any effort to produce Java bindings for the APIs

    which are at present only defined in C ?

 

Regards,

Mike

 

------------------------------

 

Date:    Thu, 23 Mar 2000 13:45:28 -0500

From:    Michael Rossi <mrossi@CRUSHER.JCALS.CSC.COM>

Subject: FW: Issues with Version 1.0 spec

 

mts@uk.ibm.com wrote:

>

> I am currently in the US (East Coast), could participate in a call

> Wednesday or Thursday next week.

 

   It sounds like Wednesday might be a good day. If anyone can't make it on

Wednesday let me know, otherwise I'll shoot for then. As for a time, I'd

like to go for about 9:00 EST (that's US East Coast). This would make it

1400 (2:00) GMT. Again, if this gives anyone heartache let me know.

 

Michael A. Rossi

mailto:mrossi@csc.com

856-983-4400 x4911

 

------------------------------

 

Date:    Thu, 23 Mar 2000 13:50:37 -0500

From:    Michael Rossi <mrossi@CRUSHER.JCALS.CSC.COM>

Subject: Re: Issues with Version 1.0 spec

 

Rob Allen wrote:

>

> The ERC is keen to take a completed 1.0 version of the spec and establish

> wf-XML in the XML world.

> This is an important positioning for all of us.

> The sooner we can make meaningful announcements the better

 

   I agree with you and Dave, and see no reason why the spec can't be

completed by next week. A bit later than hoped, but it'll be well worth it.

We then only need to decide if an interoperability test would be appropriate

before release, but we'll discuss that on the call.

 

Michael A. Rossi

mailto:mrossi@csc.com

856-983-4400 x4911

 

------------------------------

 

Date:    Thu, 23 Mar 2000 17:54:15 -0500

From:    Michael Rossi <mrossi@CRUSHER.JCALS.CSC.COM>

Subject: FW: XTech 2000 XML protocol BOF notes

 

   We've been noticed on the mailing list that's helping the W3C evaluate

the formation of an 'XML Protocols' working group. This activity has been

spurred on by the increasing popularity of things like XML/RPC, SOAP and

WDDX. The referenced archives are very interesting, the relevant thread is

about 2/3 of the way down. If anyone would care to see my response, I'll be

glad to forward it. FWIW, I really do think we should consider coordinating

with this group.

 

Michael A. Rossi

mailto:mrossi@csc.com

856-983-4400 x4911

 

 

-----Original Message-----

From: Eric Prud'hommeaux [mailto:eric@w3.org]

Sent: Thursday, March 23, 2000 3:36 PM

To: Larry Masinter

Cc: xml-dist-app@w3.org

Subject: Re: XTech 2000 XML protocol BOF notes

 

 

On Mon, Mar 20, 2000 at 06:03:54PM -0800, Larry Masinter wrote:

> Given the larger problem statements in the BOF, I think it is worthwhile

> for people to look at SWAP (Simple Workflow something Protocol) and also

the

> WfMC

> spec (www.wfmc.org) as a source of additional design insights and

> problem definition.

 

FoRK has an EDI thread that touches on SWAP and WfMC. Go to