RE: [asap] Minimum requirements

[Keith Swenson <KSwenson@fsw.fujitsu.com>]

Title: RE: [asap] Minimum requirements

The ASAP Protocol has a GetProperties and a SetProperties.  I am not complicating anything, I am asking the question: What do these operations return?  Many people will tell you that they are not prepared to handle a SetProperties reqeust.  How is this expressed?

-Keith

----------------
[Ricker] What you are proposing is way, way, way too RPC.

Webservices are much simpler. XML goes into a black box and XML comes
out. If by coincidence some elements are the same, so be it. We can see
by the schemas that the request data has some of the same elements as
the response data. Why complicate the matter?

> (3)
> I have always been concerned by the two structures: context and
> result.  Why not one structure?  Because while the structure can be
> specified using XML Schema, it is impossible to specify what parts of
> this structure flow in which direction:  what parts are IN, what parts
> are OUT, and what parts are IN/OUT.  Data fields need to play all
> three of these roles (as well as data that is local to the process and
> neither settable nor readable, but that is unimportant to the
> protocol.)  I see two options:
>
> (3a)
> Use the context data as the IN data, and the result data as the OUT
> data.  Values that are both IN and OUT would appear in both structures
> at the same XPath position.  This is consistent with current
> documents.
>
> (3b)
> Define a single structure with all data in it.  Then define a separate
> list of XPath expressions for all parts of the process which are
> settable, and another list of XPath expressions for all parts that are
> readable.
>
> An example of (3a):
>
> <ContextData>
>     <Name>John Jones</Name>
>     <SSN>123-456-7890</SSN>
>     <Zip>34567</Zip>
> </ContextData>
> <ResultData>
>     <Zip>34567</Zip>
>     <Approval>true</Approval>
> </ResultData>
>
> In this case the name, SSN, and zip are input to the process instance,
> and might be able to set with a set properties command.  The purpose
> of the process is to get approval for something, to the result data is
> the Zip and the Approval value.  Zip can both be set and read because
> it appears in both structures at the same XPath.
>
> An example of (3b):
> <Data>
>     <Name>John Jones</Name>
>     <SSN>123-456-7890</SSN>
>     <Zip>34567</Zip>
>     <Approval>true</Approval>
> </Data>
> <Writeable>
>     <Item xpath="Name"/>
>     <Item xpath="SSN"/>
>     <Item xpath="Zip"/>
> </Writeable>
> <Readable>
>     <Item xpath="Zip"/>
>     <Item xpath="Approval"/>
> </Readable>
>
> One advantage of this is a single data structure, a single schema.
> While the separate list of access control is more cumbersome, it does
> open the possibilities that the access control might change over
> time.  For example, the total value might be able to change until the
> first approval, after which it becomes non-writeable.  One might be
> able to include as part of the state the parts of the data which are
> *currently* editable.  It also opens the door for access control which
> is user-dependent.  Somehow this seems better than defining two
> structures which have overlapping parts.