Basic XML Schema Patterns for Databinding Last Call Issues List $Date: 2008/07/23 16:51:42 $ 2007-12-31 http://www.example.org/MyIssuesDir http://www.example.org/MyIssuesDir W3C XML Schema Patterns for Databinding

This is the Last Call Working Draft issues list for Basic XML Schema Patterns for Databinding Version 1.0.

Please send comments about this document to the public-xsd-databinding-comments@w3.org mailing list (see public archive).

Issues list for other deliverables of the WG can be found on the Working Group page.

being used to track Last Call Issues for the Basic Patterns document.
typo "casue" 2006-11-30 Very first sentence of the abstract in the advanced draft: "This specification provides a set of [XML Schema 1.0] patterns in common use, but which are known to casue issues with state of the art databinding implementations." casue --> cause Eliotte Harold (elharo@metalab.unc.edu) 2007-02-13

fixed typeo.

 2007-03-20 XPath 2.0 and node-set ? 2006-12-04 I just had a look at "Basic XML Schema Patterns for Databinding Version 1.0", the WD of the 22 November 2006. I'm surprised to see that expressions are based on XPath 2.0, but that the draft uses the XSLT 1.0 terminology (node-set vs/ sequence). Is there any reason to that? Florent Georges (darkman_spam@yahoo.fr) 2007-02-13

accepted proposed terminology change.

 2008-07-22 WS-I Basic Profile compliant schema import 2006-12-12 it appears that the only way to import a schema and be able to reference the elements from a WSDL message and remain Basic Profile compliant is as follows: """ <wsdl:types> <xs:schema> <xs:import namespace="http://example.com/schema" schemaLocation="schema.xsd"/> </xs:schema> </wsdl:types> """ That is, you have to use a chameleon schema which the Basic Patterns document preculudes due to known interop issues with tools. Is this constrained pattern well enough supported by tools to be included in the "Basic" document? Paul Downey (paul.downey@bt.com) 2007-02-13

accepted proposed terminology change.

 2007-02-13 Working Group member. 2007-02-13Working group member and was present. XPath Expressions Too Complex? 2007-01-04 It's not clear to me why the XPath assertions are so complicated. For instance, the following pattern: .[@targetNamespace]/ (., @targetNamespace) returns a non-empty node-set (an xs:schema element and a targetNamespace attribute) on a pattern-conforming schema. However, a simpler pattern will give us a similarly non-empty node-set: @targetNamespace or if you really think this helps set the context (I don't), it's synonym: ./@targetNamespace IMO this is simpler to read is that it is familiar to XPath 1.0 users, not just those who dive into the (distressingly complex) XPath 2.0 spec. There seems to be additional information encoded in the XPath 2.0 form, but it's not clear what it's used for, if anything, especially since this style doesn't appear in all patterns. Jonathan Marsh (jonathan@wso2.com) 2007-02-13

The working group sympathised with your point of view, the XPaths are complex but we elected to endeavor to make them consistent, each pattern in two parts, first explicitly locating a node, then selecting the nodes to be matched, rather than making the simplest patterns simpler as you suggest

 2008-07-22 2008-07-23Yes, I'm satisfied. Thanks for the response! Schema Version Attribute 2007-01-04 Pattern 2.1.4 SchemaVersion. How does the version attribute help with databinding? Seems like encouraging it's appearance (while not a bad idea) is orthogonal to the goal of mapping to data structures. Same can be said of 2.2.1 DocumentationElement, probably others as well. This seems to stray into general purpose schema subset territory. Jonathan Marsh (jonathan@wso2.com) 2007-02-13

It does stray into general purpose schema sub-setting, but the approach taken for Basic is to allow all aspects of schema, unless they are shown not to work with state of the art implementations. Our testing revealed version as having no impact, and so is "Basic", along with similar schema attributes ignored by implementations.

2008-07-22 2008-07-23Yes, I'm satisfied. Thanks for the response! Duplicate Listing 2007-01-04 Pattern 2.2.1 DocumentationElement. Listing <xs:annotation> twice (in context and out) looks like a bug in the example generation code ;-). Jonathan Marsh (jonathan@wso2.com) 2007-02-13

We believe we've resolved this issue. Thanks for noticing!

2008-07-22 2008-07-23Yes, I'm satisfied. Thanks for the response! Value of @mixed="false" etc 2007-01-04 The patterns are written in terms of "a document exhibits a pattern when .". An effect of this is that a pattern may return a node-set even when parts of the document don't exhibit the pattern, or exhibit the opposite of the pattern. For instance 2.3.3 NotMixed says a document exhibits a pattern when there is at least one instance of @mixed="false", but the information a user is most likely to want is whether the schema exhibits any undesirable patterns, such as the (likely problematic) @mixed="true". In essence, the granularity implied with the statement "An [XML 1.0] document exhibits the NotMixed pattern" doesn't seem to be terrible useful, and contrary to the name, does not ensure a schema doesn't allow mixed content. It might be as simple as changing the expression to something like @mixed!='true', or there might be a larger problem with the granularity here. Jonathan Marsh (jonathan@wso2.com) 2007-02-13

We allow explicitly asserting the default value for attributes such as "mixed" for similar reasons as to why we allow the "version" attribute.

2008-07-22 2008-07-23Yes, I'm satisfied. Thanks for the response! Grouping of R2800 and R2112 2007-01-04 Appendix C why is R2800 not grouped with R2112? They seem to be introduced the same way. Jonathan Marsh (jonathan@wso2.com) 2007-02-13

Reading the specification with fresh eyes, I understand the confusion, but the rationale behind the grouping, which we've maintained is R2112 is something allowed by the Basic patterns document, but explicitly disallowed by the WS-I BP, whereas R2800 is a case where the WS-I BP is less constrained than the Basic patterns document

2008-07-22 2008-07-23Yes, I'm satisfied. Thanks for the response! Document or Element Node 2007-01-15 Everywhere it says "document or element node", I think it should just say "element node". A document node would never be returned by .//xs:schema; the xs:schema element would be a child of the document node in the case that it was the outermost element. Priscilla Walmsley (pwalmsley@datypic.com) 2007-02-13

Accepted suggested terminology

 2007-02-13Working group member 2007-02-13Working group member and was present. "node-set" should be "sequence" 2007-01-15 Everywhere it says "node-set" it should say "sequence". Priscilla Walmsley (pwalmsley@datypic.com) 2007-02-13

Accepted suggested terminology

 2007-02-13Working group member 2007-02-13Working group member and was present. QualifiedLocalElements 2007-01-15 It might be more illustrative to show an example of a locally declared element in the schema and have the instance element be prefixed Priscilla Walmsley (pwalmsley@datypic.com) 2007-02-13

Example doesn't have elements.

 2007-02-13Working group member 2007-02-13Working group member and was present. UnqualifiedLocalElements 2007-01-15 It might be more illustrative to show an example of a locally declared attribute in the schema and have the instance element carry that attribute Priscilla Walmsley (pwalmsley@datypic.com) 2007-02-13

as for lc-pwalmsley-3

 2007-02-13Working group member 2007-02-13Working group member and was present. ElementFinal 2007-01-15 Only global elements can validly have the @final attribute, so the path could start with ./xs:element instead of .//xs:element Priscilla Walmsley (pwalmsley@datypic.com) 2007-02-13

accepted modification to ElementFinal pattern

 2007-02-13Working group member 2007-02-13Working group member and was present. ImportTypesNamespace 2007-01-15 I don't see how this could represent a valid schema, since the XML Schema recommendation says, about import, "If the namespace [attribute] is present, then its .actual value. must not match the .actual value. of the enclosing <schema>'s targetNamespace [attribute]." Priscilla Walmsley (pwalmsley@datypic.com) 2007-02-13

captures a common pattern used within WSDL documents

 2007-02-13Working group member 2007-02-13Working group member and was present. GlobalElement and GlobalAttribute 2007-01-15 The "@name and " is redundant since all global element/attribute declarations have to have name attributesPriscilla Walmsley (pwalmsley@datypic.com) 2007-02-13

simplified pattern XPaths as suggested

 2007-02-13Working group member 2007-02-13Working group member and was present. @type colon 2007-01-15 I'm not clear why we're checking whether @type contains a colon? The type attribute could still contain a name that's in a namespace but not prefixed, if a default namespace is declared. Is it because some processors might handle prefixed names differently from non-prefixed ones? If this is the case, shouldn't we have two patterns: GlobalElementPrefixedType and GlobalElementUnprefixedType? Same comment on ElementTypeReference ElementReference, AttributeTypeReference, and AttributeReferencePriscilla Walmsley (pwalmsley@datypic.com) 2007-02-13

a client also encountered this issue, so happy to withdraw the comment

 2007-02-13Working group member 2007-02-13Working group member and was present. GlobalElementSequence 2007-01-15 This pattern doesn't rule out types where there is something else besides elements in the sequence, for example: <xs:element name="globalElementSequence"> <xs:complexType> <xs:sequence> <xs:element name="foo" type="xs:string" /> <xs:element name="bar" type="xs:string" /> <xs:choice> <xs:any/> <xs:group ref="xxx"/> </xs:choice> </xs:sequence> </xs:complexType> </xs:element> It seems that such a type shouldn't conform to a basic pattern. Maybe it should be something like: ./xs:element/xs:complexType/xs:sequence[xs:element and not(* except (xs:element, xs:annotation))]/ Or is the idea that it's the foo and bar elements that are the ones that conform to the pattern? Same comment for ComplexTypeSequencePriscilla Walmsley (pwalmsley@datypic.com) 2007-02-13

accepted proposed change

 2007-02-13Working group member 2007-02-13Working group member and was present. ElementMaxOccursFinite 2007-01-15 Could be simplified: .//xs:element[@maxOccurs != ('0','1','unbounded')]Priscilla Walmsley (pwalmsley@datypic.com) 2007-02-13

accepted proposed change

 2007-02-13Working group member 2007-02-13Working group member and was present. ElementEmptySequence @name 2007-01-15 The [@name] is redundant because an xs:element without a name could never have a complexType child Priscilla Walmsley (pwalmsley@datypic.com) 2007-02-13

accepted proposed change

 2007-02-13Working group member 2007-02-13Working group member and was present. ElementEmptySequence not(node()) 2007-01-15 Instead of not(node()) which would return true even if there was <sequence> </sequence>, should it be not(*) or not (* except xs:annotation)Priscilla Walmsley (pwalmsley@datypic.com) 2007-02-13

accepted proposed change

 2007-02-13Working group member 2007-02-13Working group member and was present. ElementEmptyComplexType @name 2007-01-15 The [@name] is redundant because an xs:element without a name could never have a complexType childPriscilla Walmsley (pwalmsley@datypic.com) 2007-02-13

accepted proposed change

 2007-02-13Working group member 2007-02-13Working group member and was present. ElementEmptyComplexType not(node()) 2007-01-15 Instead of not(node()) which would return true even if there was <complexType> </complexType>, should it be not(*) or not (* except xs:annotation)Priscilla Walmsley (pwalmsley@datypic.com) 2007-02-13

accepted proposed change

 2007-02-13Working group member 2007-02-13Working group member and was present. Global SimpleType Declarations 2007-01-15 Section title "Global SimpleType Declarations" - Technically, according to the Schema rec, types have _definitions_ and elements/attributes have _declarations_, so this should be changed to "Global SimpleType Definitions". (May occur in other places too.) Priscilla Walmsley (pwalmsley@datypic.com) 2007-02-13

accepted proposed change

 2007-02-13Working group member 2007-02-13Working group member and was present. GlobalSimpleType and GlobalComplexType 2007-01-15 [@name] is redundant since top-level complex types always have namesPriscilla Walmsley (pwalmsley@datypic.com) 2007-02-13

accepted proposed change

 2007-02-13Working group member 2007-02-13Working group member and was present. StringEnumerationType 2007-01-15 The path doesn't eliminate simple types that combine xs:enumeration with other facets. Should it? I wouldn't think the following type would conform to the basic pattern: <xs:simpleType name="Beatle"> <xs:restriction base="xs:string"> <xs:enumeration value="John" /> <xs:enumeration value="Paul" /> <xs:enumeration value="George" /> <xs:whiteSpace value="collapse"/> <xs:maxLength pattern=".{4,6}"/> </xs:restriction> </xs:simpleType> Priscilla Walmsley (pwalmsley@datypic.com) 2007-02-13

withdraw that one, cathcall picks it up

 2007-02-13Working group member 2007-02-13Working group member and was present. Support for Attributes 2007-01-15 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. Eugene Osovetsky (Eugene.Osovetsky@microsoft.com) Element References 2007-01-15 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. Eugene Osovetsky (Eugene.Osovetsky@microsoft.com) Nested Sequences and sequences other than minOccurs=maxOccurs=1 2007-01-15 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. Eugene Osovetsky (Eugene.Osovetsky@microsoft.com) schemaLocation 2007-01-15 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. Eugene Osovetsky (Eugene.Osovetsky@microsoft.com) maxOccurs=finite 2007-01-15 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. Eugene Osovetsky (Eugene.Osovetsky@microsoft.com) Null enumerations 2007-01-15 Could you please clarify the purpose of pattern 2.11.3? Eugene Osovetsky (Eugene.Osovetsky@microsoft.com) Mixing elements maxOccurs=1 and maxOccurs>1 in the same sequence, or allowing more than one maxOccurs>1 element 2007-01-15 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. Eugene Osovetsky (Eugene.Osovetsky@microsoft.com) Mixing elements maxOccurs=1 and maxOccurs>1 in the same inheritance chain 2007-01-15 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.. Eugene Osovetsky (Eugene.Osovetsky@microsoft.com) BOM link to Unicode FAQ 2007-01-15 http://www.w3.org/TR/2006/WD-xmlschema-patterns-20061122/#document-conformance describes how an XML Schema document should look like , to ease processing with data binding tools. You have also recommendations about the BOM. It would be great if you could add a link to the Unicode FAQ on the BOM http://www.unicode.org/unicode/faq/utf_bom.html#BOM , to provide implementers with a way to get more detailed information. Felix Sasaki (fsasaki@w3.org) 2007-02-13 Working with Time Zones 2007-01-15various subsections in http://www.w3.org/TR/2006/WD-xmlschema-patterns-20061122/#group-ElementPredefinedTypes and http://www.w3.org/TR/2006/WD-xmlschema-patterns-20061122/#group-AttributePredefinedTypes talk about time / date related patterns, see subsections 2.14.6 - 2.14.11, also 2.15.6 - 2.15.11 . It would be great if you could add a note pointing to the document "Working with Time Zones" http://www.w3.org/TR/2005/NOTE-timezone-20051013/ . It provides information e.g. about the difference between dateTime in XML Schema vs. programming languages, which seems to be relevant for your audience. Felix Sasaki (fsasaki@w3.org) language type to reference BCP47 2007-01-15 subsections 2.14.17 and 2.15.17 , on the LanguageElement / LanguageAttribute . The definition of the language type at http://www.w3.org/TR/xmlschema-2/#language refers only to RFC 3066 and the pattern [a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})* . It would be great if you could point to BCP 47 instead, see http://www.rfc-editor.org/rfc/bcp/bcp47.txt . BCP 47 is the "Best Common Practice" for language identification. Currently, BCP 47 is represented by the successor of RFC 3066, which is RFC 4646 (Tags for Identifying Languages) and RFC 4647 (Matching of Language Tags). Felix Sasaki (fsasaki@w3.org) xs:date and xs:time patterns not well suported by implementations 2007-04-20 from testing with toolkits it seems that a number of implementations treat the abstract xs:time value "00:00:00" as being a concrete "00:00:00Z" or worse "09:30:00" depending on the local time of the service. The same issue applies to the other partial date and time types. I therefore suggest patterns which involve xs:time, xs:date, and xs:G{Year|Month|Day}* be moved to "Advanced" Paul Downey (paul.downey@bt.com) Difficulty to read patterns as expressed with XPath 2.0 2007-04-20 The patterns in the XML Schema Patterns for Databinding specifications are written as XPath 2.0 expressions. While this makes them compact, very well defined, and checkable automatically with tools, it makes it hard for an average developer to read the specification. Developers may generally be familiar with XPath 1.0, but this is not the case with XPath 2.0 at this point. The document would greatly benefit from: - an introductory section about how XPath 2.0 is used and how to read the type of XPath 2.0 expressions used in the document. I would recommend illustrating this XPath 2.0 by using a non-trivial expression, and walking through it with examples to help readers understand. - examples for each variation of each pattern described; for example, in the Basic Patterns specification, 2.12.3 ComplexTypeAttributeExtension does not have any examples and is not easy to read. I believe that the documents produced by this working group are very useful to Web services developers. It's therefore important to make it understandable to the largest audience possible. Hugo Haas (hugo@yahoo-inc.com) References to concepts and terminology from XSD need to be made more precise 2008-02-15 References to concepts and terminology from XSD need to be made more precise. For example, section 1.3 says "A document claiming conformance to this specification ... MUST conform to the [XML Schema 1.0 Recommendation]", but XSD provides no conformance requirements for "documents" in general. It would be more appropriate to say that "A document claiming conformance to this specification ... MUST be a 'schema document' [2], as defined in [XML Schema 1.0 Recommendation], and MUST therefore meet the "Constraints on the representation of schema components in XML" [3] provided therein." Actually, there's a further mismatch on infosets vs. serialization; see next point. Noah Mendelsohn (noah_mendelsohn@us.ibm.com) 2008-03-11

Accepted suggested terminology.

 2008-07-22