- 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
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:28:56 UTC