- From: George Cowe <gcowe@origoservices.com>
- Date: Tue, 23 Jan 2007 09:29:43 -0000
- To: public-xsd-databinding@w3.org
For info. Origo has summarised its points of view on Microsoft's comments. I have fed these back to a number of Life and Pensions organisations who are on our WS-Adoption discussion list as they directly affect them. George -----Original Message----- From: wsadoption@lists.origostandards.org [mailto:wsadoption@lists.origostandards.org] On Behalf Of George Cowe Sent: 22 January 2007 14:49 To: Web Services Adoption Working Group Discussion List. Subject: [WS-Adoption] FW: Microsoft Comments on Basic Schema Patterns fordata binding Below I have documented Origo's response to Microsoft's points on schema design with a view to easing data-binding for Web Services. http://lists.w3.org/Archives/Public/public-xsd-databinding-comments/2007Jan/0002.html Each response is blocked in a ORIGO RESPONSE section. If anyone has any comments please feed them back to us. Thanks George MICROSOFT'S COMMENTS Dear members of the XML Schema Patterns for Databinding Working Group, Me and Kirill Gavrylyuk from Microsoft's Web Services team (Windows Communication Foundation) have reviewed the document at http://www.w3.org/TR/2006/WD-xmlschema-patterns-20061122/. Thank you for the detailed work in this area - I firmly believe that a thorough study of common schema patterns such as the one you produced is exactly what is needed to move us in the right direction. We have a few observations about some of the patterns mentioned in the document (from the point of view of data binding specifically in the context of Web Services) and would really appreciate getting your thoughts on these. -- Eugene Osovetsky, Program Manager, WCF Data/Serialization ___________________________________________________________________ ORIGO RESPONSE A number of comments made here seem to be looking at schema as something that is only produced by programming tools as a result of describing an API. This is fine if your only use case is XML-RPC. However, the majority of schema defined in the wild today are concerned with "document literal" definitions of business data and constraints on that data, that model the real world. This definition work being done in the abstract, before system development takes place in most situations. All the suggested alternative approaches to getting round the problems with databinding tools could be used, but would impact on the resulting XML data structures by adding redundancy, complexity or to reduce the level of business semantics contained, for no reason other than to make them work with the tools. In most situations we've encountered, the business has a great deal of control and say in how schema are developed. And they (the business) are not happy with "oh, we need to do it that way so that they work with tool xyz, who one of our trading partners may use" is not acceptable to them. The patterns we specify as required, we believe, represent "useful" and in some cases "best practice" for XML design, we also think they should be relatively simple for databinding tools to support. The Origo response for each pattern commented on by Microsoft follows - __________________________________________________________________ 1. Support for Attributes We observed that usage of attributes in XML Schema for Web Service scenarios is problematic for the reasons listed below. We suggest to discourage use of attributes in WebServices / data binding domain by eliminating patterns 2.6.1, 2.8.*, 2.12.1, 2.12.3, 2.15.* from the specification. - Attributes provide a subset of data encapsulation functionality provided by elements as detailed below. It seems beneficial to strive to minimize the number of alternative abstractions used for the same purpose, and elements provide a better and more widely adopted choice. o There are no null semantics for attributes - there is either default value or undefined value. o Complex types are not easily represented in attributes o Support for lists in attributes is limited and not widely adopted - Attribute have different name scopes with elements and hence require name mangling in data binding if both elements and attributes are in use - Traditionally attributes are used for metadata about the element contents - that is, they may be used to control the binding by some processors. - For query scenarios there is no good adopted serialization format for query result that contains only attribute nodes. - Support for instance documents where xsi:nil=true yet attributes are set to meaningful values is limited. Discouraging the use of attributes eliminates problems related to this pattern. ___________________________________________________________________________________________________ ORIGO RESPONSE Attributes are useful when used as metadata to describe the contents of an element and its children. Also ensure that this definition (the attribute) cannot be extended. For example an attribute could be used to represent the currency on a monetary transaction element. 2.6.1 - GlobalAttributes - agree these should not be used 2.8.* - Attribute declarations - Origo require these to be supported 2.12.1 - ComplexTypeAttribute - agree these should not be used 2.12.3 - ComplexTypeAttributeExtension - agree these should not be used 2.15.* - AttributePredefinedTypes - Origo require these to be supported. For this reason we would like to see support for Attributes in data binding tools. ___________________________________________________________________________________________________ 2. Element references Element references have no natural equivalent construct (globally defined local field) in modern programming languages. We suggest to discourage schema authors from using them by eliminating pattern 2.7.15 from the specification. ___________________________________________________________________________________________________ ORIGO RESPONSE - Agree these should not be used ___________________________________________________________________________________________________ 3. Nested sequences and sequences other than minOccurs=maxOccurs=1 Generally, these patterns do not add much to the space of possible data models, but add complexity. Specifically: - A minOccurs=1,maxOccurs=1 sequence nested in another sequence is equivalent to unwrapping the inner sequence - An optional sequence (minOccurs=0), though useful in representing "all or none" semantics, can be simplified by unwrapping and using optional elements or by wrapping the sequence's elements in a separate type if true all-or-none semantics are needed. Most modern programming languages cannot represent "all or none" semantics without wrapping. - A repeating sequence (maxOccurs=1), while useful for representing repeated data, can be simplified by wrapping the sequence's elements in a separate type. Most modern programming languages cannot represent repetition semantics without wrapping. Also, support for such constructs in many platforms is either limited, bug-prone or non-existent. We suggest to discourage schema authors from using these patterns by eliminating patterns 2.13.1, 2.13.2, 2.13.5, 2.13.6, 2.13.7 from the specification. ___________________________________________________________________________________________________ ORIGO RESPONSE We have a specific business requirement to support some of these patterns. For example managing errors which may or may not exist. 2.13.1 - SequenceSequenceElement - agree this should not be used 2.13.2 - SequenceMinOccurs0 - Origo require this to be supported 2.13.5 - SequenceMinOccurs0MaxOccursUnbounded - Origo require this to be supported 2.13.6 - SequenceMinOccurs1MaxOccursUnbounded - Origo require this to be supported 2.13.7 - SequenceMaxOccursFinite - Origo require this to be supported ___________________________________________________________________________________________________ 4. schemaLocation For security reasons, some implementations may choose not to follow schemaLocation reference. We suggest the working group to clarify patterns 2.4.3 and 2.4.4 by saying that an implementation MAY ignore the schemaLocation attribute if it provides an alternative way to specify the location of schema. ___________________________________________________________________________________________________ ORIGO RESPONSE - agreed but possibly this should be optional. ___________________________________________________________________________________________________ 5. maxOccurs=finite A finite maxOccurs setting unnecessarily complicates the content model created by some schema processors. Additionally, it is not common for implementations to actually enforce a finite maxOccurs constraint. We suggest the working group should recommend against using patterns 2.7.6 and 2.13.7 (also see note #3 above with regards to 2.13.7), or even consider removing them from the specification. ___________________________________________________________________________________________________ ORIGO RESPONSE We have a specific business requirement to support a finite occurrence of elements. For example http://www.govtalk.gov.uk/gdsc/schemaHtml/AddressTypes-v1-4-xsd-UKPostalAddressStructure.htm The UK Government Data Standards Catalogue is one instance of this and there are many more. For this reason we would like to see this supported in data binding tools. ___________________________________________________________________________________________________ 6. Null enumerations Could you please clarify the purpose of pattern 2.11.3? 7. Mixing elements maxOccurs=1 and maxOccurs>1 in the same sequence, or allowing more than one maxOccurs>1 element The combination of patterns 2.7.4, 2.7.5, 2.7.6 (elements with maxOccurs>1) and 2.5.4, 2.12.2 (global and complex type sequences) seems to imply that such cases are allowed. Bare arrays do not support the distinction between null arrays and empty arrays. We suggest to recommend wrapped collection pattern as preferred and exclude bare array pattern. ___________________________________________________________________________________________________ ORIGO RESPONSE Using the wrapped collection pattern may help databinding but is not the natural way to design schemas. 2.7.4 - ElementMinOccurs0MaxOccursUnbounded - Origo require this to be supported 2.7.5 - ElementMinOccurs1MaxOccursUnbounded - Origo require this to be supported 2.7.6 - ElementMaxOccursFinite - Origo require this to be supported 2.5.4 - GlobalElementSequence - Origo require this to be supported 2.12.2 - ComplexTypeSequence - Origo require this to be supported ___________________________________________________________________________________________________ 8. Mixing elements maxOccurs=1 and maxOccurs>1 in the same inheritance chain Pattern 2.12.4 does not place any restrictions on inheritance that would prevent a type with a sequence with all maxOccurs=1 elements extending a type with a sequence with a maxOccurs>1 element, or vice versa. Such inheritance may be problematic (see note 7 above). Implementations may choose to map maxOccurs>1 to collections, and in many languages it is problematic to inherit a collection/array type from a non-collection type or vice versa and yet keep the correct serialization semantics. We suggest to exclude such patterns and recommend inheritance for structs separately from inheritance for collections.. ___________________________________________________________________________________________________ ORIGO RESPONSE We have a specific business requirement to support a finite occurrence of elements. 2.12.4 - ComplexTypeSequenceExtension - Origo require this to be supported ___________________________________________________________________________________________________ George Cowe Standards Architect Origo Services Ltd Tel: 0131 451 1179 Email: gcowe@origoservices.com _______________________________________________ WSAdoption mailing list WSAdoption@lists.origostandards.org http://lists.origostandards.org/mailman/listinfo/wsadoption
Received on Tuesday, 23 January 2007 09:30:18 UTC