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

re: On removing messages

From: FABLET Youenn <youenn.fablet@crf.canon.fr>
Date: Mon, 03 Feb 2003 11:32:19 +0100
Message-ID: <3E3E4533.1090002@crf.canon.fr>
To: Roberto Chinnici <roberto.chinnici@sun.com>, www-ws-desc@w3.org
CC: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>

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 05:33:16 UTC

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