[Standards] Re: Feedback on I/O Object Forms

Egon Willighagen egon.willighagen at gmail.com
Sat Mar 17 11:22:04 UTC 2007


Hi Chris,

thank you very much for this valuable input! See my replies on a couple of
things below.

Chris Mullins wrote:
> Essentially (this is me talking, interpreting what I think the XEP
> author said), they're looking to replace SOAP Based Web Services with
> XMPP Based services. They're looking to do this due to the nature of
> their very long running transactions and the ability of an XMPP Service
> to send an "all done" message, and for the client to get it at some
> point in the future. The Async Nature of XMPP is really the main reason
> for things.

Yes, the Async nature is indeed rather important. Both in chemistry and
bioinformatics jobs can take up hours or longer, as they are not simple
database lookup, but actual time-consuming computations.
 
> (Overall, I quite like the goals here. I think building rich Services
> atop XMPP will be important to the long term success of the protocol, as
> well as the continued divergence from "just an IM protocol".)
> 
> Upon first read of the XEP, I didn't understand this - so clarity was
> (for me) missing.

I found that two when I read the first draft, but blamed it on my lack of
knowledge of the Jabber protocols; I'm a chemoinformtician myself. I did
read up on things, and I thought we had things reasonably sorted out. We
will clarify things a bit more, as result of this discussion.

<snip>

> The XEP author is defining a custom namespace, called Object Spaces, in
> which parameters can be passed to & from the Service. These are defined
> to look like:
> 
> <x xmlns='http://xmpp.org/protocol/io-object-form' type='submit'>
> 
>         <in>
> 
>                 <proteinname>CAB08284</proteinname>
> 
>         </in>
> 
> </x>
> 
> I don't understand how this differs from an X-Data Form. The author
> keeps saying that X-Data won't do the trick, but either I'm missing
> something or the author is missing something. I don't understand why,
> during discover, the service wouldn't send back a data form (this is the
> required argument list):
> 
> <x xmlns='jabber:x:data' type='form'>
>       <title>Method Arguments</title>
>       <field type='hidden' var='FORM_TYPE'>
>         <value>Object Spaces</value>
>       </field>
>       <field type='text-multi' var='proteinname'><required/></field>
> </x>
>     
> .. and the client would then fill this form out as a submit form:
> <x xmlns='jabber:x:data' type=submit>
>       <field type='hidden' var='FORM_TYPE'>
>         <value>Object Spaces</value>
>       </field>
>       <field type='text-multi'
> var='proteinname'><value>0</value></field>
> </x>

The important difference is the <value> element. X-Data only allows
xsd:string as content. However, we would like to make it possible for the
service to be more restrictive in the content of string: we want it to be
XML. That is, we would like the service to require e.g. Chemical Markup
Language input, or other XML namespaces, instead of just a string which
happens to be XML.

Therefore, we have in the schema:

<xs:element name='in'>
  <xs:choice>
    <!-- for x at type='form' : -->
    <xs:any namespace='http://www.w3.org/2001/XMLSchema'
            minOccurrence='1' maxOccurence='1'/>
    <!-- for x at type='submit,results,etc' : -->
    <xs:any namespace='##other' processContents='strict'/>
  </xs:choice>
</xs:element>

I am not entirely happy that the current schema cannot distinguish between
the form type and the other types, and rather interested in thoughts about
that.

> The resulting message would also have an X-Data from sent from the
> server back to the client with the results.
> 
> I can see defining some new field types:
> 
> -          Base64 Binary Data
> -          XML Data

The latter is of our prime interest, as explained above.

However, I do not see how we can define new fields in a existing XEP in
final state. How would that go about? The X-Data does not seem to allow
putting restrictions on the data types in <value>.

> I understand the argument, "This is machine to machine communication,
> and X-Data is meant for human-to-machine communication", but I think
> it's flawed. X-Data (to me) seems to allow machine-to-machine with no
> trouble.

Agreed, with the exception that services cannot advertise that it requires
XML type for <field>'s. The X-Data only mentions

<xs:simpleType>
  <xs:restriction base='xs:NCName'>
    <xs:enumeration value='boolean'/>
    <xs:enumeration value='fixed'/>
    <xs:enumeration value='hidden'/>
    <xs:enumeration value='jid-multi'/>
    <xs:enumeration value='jid-single'/>
    <xs:enumeration value='list-multi'/>
    <xs:enumeration value='list-single'/>
    <xs:enumeration value='text-multi'/>
    <xs:enumeration value='text-private'/>
    <xs:enumeration value='text-single'/>
  </xs:restriction>
</xs:simpleType>

which does not really suited for machine-to-machine communication.

Am I misunderstanding something here?

<snip>

I leave your proposed change to the JID for the async communication to
Julian, who is more into that side of the proposal.

Egon

-- 
e.willighagen at science.ru.nl
Cologne University Bioinformatics Center (CUBIC)
Blog: http://chem-bla-ics.blogspot.com/
GPG: 1024D/D6336BA6



More information about the Standards mailing list