W3C home > Mailing lists > Public > www-ws-desc@w3.org > February 2003

Re: On removing messages

From: Steve Graham <sggraham@us.ibm.com>
Date: Mon, 3 Feb 2003 07:51:40 -0500
To: "FABLET Youenn" <youenn.fablet@crf.canon.fr>
Cc: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>, Roberto Chinnici <roberto.chinnici@sun.com>, www-ws-desc@w3.org
Message-ID: <OF9044911E.DE5526D8-ON85256CC2.0046838A@us.ibm.com>

Outside of serviceData, we do not plan on additional constructs to WSDL.

We are working on a revised draft of the Grid Services Spec.  In this spec
will be a complete description of ServiceData.

Meanwhile, [1] gives a good review of the direction we are heading (some of
the details have changed since [1] was posted).


Steve Graham
(919)254-0615 (T/L 444)
Emerging Technologies

                      "FABLET Youenn"                                                                                                  
                      <youenn.fablet@cr        To:       Steve Graham/Raleigh/IBM@IBMUS                                                
                      f.canon.fr>              cc:       Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>, Roberto Chinnici      
                                                <roberto.chinnici@sun.com>, www-ws-desc@w3.org                                         
                      02/03/2003 07:45         Subject:  Re: On removing messages                                                      

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.

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

> (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
>Steve Graham
>(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
>                      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 08:00:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:28 UTC