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:22:46 -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: <OF3F15D963.51973A1D-ON85256CC2.00435052@us.ibm.com>

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 messages                                                      
                      02/03/2003 05:32                                                                                                 

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.

Received on Monday, 3 February 2003 07:28:56 UTC

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