7 messages in org.oasis-open.lists.asapRE: [asap] Minimum requirements| From | Sent On | Attachments |
|---|---|---|
| Jeffrey Ricker | Nov 10, 2003 9:14 am |  .doc |
| John Fuller | Nov 11, 2003 12:33 pm | |
| Jeffrey Ricker | Nov 11, 2003 1:14 pm | |
| Keith Swenson | Nov 17, 2003 8:52 am | |
| Jeffrey Ricker | Nov 18, 2003 7:29 am | |
| Keith Swenson | Nov 18, 2003 9:07 am | |
| Keith Swenson | Nov 18, 2003 9:18 am |
| Subject: | RE: [asap] Minimum requirements | |
|---|---|---|
| From: | Keith Swenson (KSwe...@fsw.fujitsu.com) | |
| Date: | Nov 18, 2003 9:18:44 am | |
| List: | org.oasis-open.lists.asap | |
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.