W3C home > Mailing lists > Public > ietf-swap@w3.org > October 1998

Re: data parameter elements

From: james anderson <James.Anderson@mecomnet.de>
Date: Thu, 15 Oct 1998 13:30:29 +0000
Message-ID: <3625F8EE.88225CF4@mecomnet.de>
To: ietf-swap@w3.org
hello again,

thanks for the answers.
i agree with the intent, but i remain unconvinced that the present proposal
achieves them.


> Hi James,
>   My feeling is that, yes, this is a way to accomplish this,
> but I would classify your suggestion in the category of "Wwhy don't
> we just use {IPP, XML/RPC, HTTP, WebDAV...}?  There's a tradeoff
> at work here.  SWAP needs to define a common set of goals that
> almost all workflow tool vendors need from theirs and other
> systems.   Communicating across the network you have any
> number of transport mechanisms.

i'm not referring to the transport mechanism.
i am asking about the content model chosed for the data element.

>                                  the Goal of SWAP is to provide
> richer transport and simpler notification than existing
> network interfaces that can be standardized.   One one end of
> the spectrum, you can simply use HTTP(/1.1) and embed all
> or your smarts into an XML form.  This is similar to the WfMC's
> Mime bindings.  While the transport is simple, the overhead
> of computing smarts on the receiving end to accomplish a task
> requires a) a lot of agreements and understanding between the
> two sites,

the two processes will need to agree, in any case, as to the names, the value
domains, and the semantics for all parameters. requiring them to decode
parameters from a list of name/value items is actually an added burden. the
way xml development is going, direct serialization of (for example) java
objects to an xml-encoded stream / internalizing from such a stream will
require less application code than interpreting name/value pairs. in addition,
if an arbitrary content model is supported, the receiver could well rely on
library support to validate the respective elements instead of implementing
the completeness checks on the value lists. again using the potential offerred
by xml would lead to a simpler application.

> ...
> Take your example and write out the complete call.
> I am assuming your are invoking a remote workflow service.
> Write out, what does the  URI look like, how are the parameters
> and data encoded, is the message synchronous or asynchronous,
> what are the side-effects and results, what are the message
> and error codes, what are the return values, how do you
> use these values to accomplish the other goals?  The
> devil's always in the details.
> 
i'm enquiring about an alternative to exactly one element in the dtd
>  >
>  > <!ELEMENT swap (interfaces, ..., data?) >
>  > <!ELEMENT data ANY >
>  >

i'm not discussing transport issues, URI encoding, synchronous/asynchronous
processing; just how the parameters are encoded.

the example from section 4.3 of SWAP9807.html implies that an encoding of the
form which i mentioned above would be possible:

      <swap>
       <interfaces>ProcessInstance</interfaces>
       <key>http://myServer/app1?proc=889</key>
       <validStates>
           <li>open.notRunning</li>
           <li>open.running</li>
           </validStates>
       <state>open.notRunning</state>
        <data> 
           <d:city>San Francisco</d:city>
           <d:state>California</d:state>
           </data>
       </swap>

according to this example, applications could well encode the data as

        <data> 
           <d:location>
              <d:city><d:name>San Francisco</d:name>
                   <d:population>a lot of people</d:population></d:city>
              <d:state>California</d:state>
              </d:location>
           </data>

the discussion of PROPFIND in section 5.1, on the other hand, describes an
encoding more like

        <data>
          <item><name>city</name>
                <value>San Francisco</value></item>
          <item><name>state</name>
                <value>California</value></item>
           </data>

a) i find the two descriptions to be inconsistent.
b) if the section 5.1 discription is, in fact, the intended encoding, it will
entail more application code than the encoding which follows the section 4.3
example, and, as such, does contribute to simplicity...
Received on Thursday, 15 October 1998 07:30:23 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 22 March 2009 02:44:17 GMT