- From: FABLET Youenn <youenn.fablet@crf.canon.fr>
- Date: Mon, 03 Feb 2003 13:45:03 +0100
- To: Steve Graham <sggraham@us.ibm.com>
- CC: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>, Roberto Chinnici <roberto.chinnici@sun.com>, www-ws-desc@w3.org
I do not follow actively the grid activity and I would be interested in
some information about the additional constructs you are planning to
add/have added in WSDL for the grid purpose.
Could you send us a list of/some links to those constructs.
Thanks,
Youenn
Steve Graham wrote:
>FWIW, we faced a similar problem in the Grid services work in the Global
>Grid Forum.
>Because we are working with "stateful" Web services (for example,
>representing systems resources like storage units, servers etc.) we chose
>to formally model elements of the publically available state in WSDL
>portTypes. These elements are called serviceData [1].
>
>We struggled with a similar concept in formalizing serviceData. We ended
>up modelling serviceData as a restriction on xsd:element to capture
>precisely the subset of xsd:element that made sense for modelling
>publically available state data.
>
>At some point, Steve and I would like to discuss serviceData in this group
>with the possible consideration of including this in WSDL 1.2
>
>
>[1]http://www-unix.gridforum.org/mail_archive/ogsi-wg/2002/Archive/msg00759.html
> (Note: this is a slightly out of date reference, the most up to date
>articulation of serviceData will appear in the upcoming draft of the Grid
>Services spec. The upcoming changes are at the details level, not
>concept).
>++++++++
>Steve Graham
>sggraham@us.ibm.com
>(919)254-0615 (T/L 444)
>Emerging Technologies
>++++++++
>
>
>
>
> "FABLET Youenn"
> <youenn.fablet@cr To: Roberto Chinnici <roberto.chinnici@sun.com>, www-ws-desc@w3.org
> f.canon.fr> cc: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>
> Sent by: Subject: re: On removing messages
> www-ws-desc-reque
> st@w3.org
>
>
> 02/03/2003 05:32
> AM
>
>
>
>
>
>
>
>Traditionnaly, the xsd:element construct is used to model an xml element.
>The current proposal (correct me if I am wrong) uses also this construct
>to encapsulate non-xml data or non-schema-typed xml data, which seems to
>be another semantic.
>
>While I agree that some properties/functionnalities of xsd:element
>(minOccurs, maxOccurs, the possibility to be the child of xsd:choice...)
>are very interesting, I am not sure that all of them make sense.
>For instance, the proposal was (?) to add a mime:type attribute to an
>xsd:element instance to model a non-xml data "construct".
>This particular xsd:element instance should (must ?) be constrained to
>have no xsd children, following the schema spec behaviour. I am not sure
>that the XML-Schema spec would enforce this constraint directly (the
>mime:type attribute is in the mime namespace).
>
>IMHO, we are searching for a construct quite similar to the xsd:element
>but a little bit more constrained (fewer properties, no xml-schema
>children in it) and with a sligthly different semantic.
>Would it better to add another construct for the purpose of clarity,
>readability and accuracy, the tradeoff being a (small ?) increase of the
>complexity ? I am not sure of the answer...
>Thoughts ?
>Also to be noted that this proposal might have a larger scope than WSDL.
>
> Youenn
>
>
>
>
>
>
>
Received on Monday, 3 February 2003 07:45:57 UTC