- From: FABLET Youenn <youenn.fablet@crf.canon.fr>
- Date: Mon, 03 Feb 2003 11:32:19 +0100
- 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.
Youenn
Received on Monday, 3 February 2003 05:33:16 UTC