Feedback on http://www.w3.org/TR/2006/WD-xmlschema-patterns-20061122/

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

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.

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.

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.

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.

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.

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.

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..