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.
Color key: error warning note
Id:Title | State | Type | Ack. |
---|---|---|---|
lc-erh-1 : typo "casue" | agreed | editorial | No reply from reviewer |
lc-drkm-1 : XPath 2.0 and node-set ? | agreed | editorial | No reply from reviewer |
lc-psd-1 : WS-I Basic Profile compliant schema import | agreed | proposal | Agreement |
lc-jmarsh-1 : XPath Expressions Too Complex? | declined | editorial | Agreement |
lc-jmarsh-2 : Schema Version Attribute | declined | editorial | Agreement |
lc-jmarsh-3 : Duplicate Listing | agreed | editorial | Agreement |
lc-jmarsh-4 : Value of @mixed="false" etc | rejected | editorial | Agreement |
lc-jmarsh-5 : Grouping of R2800 and R2112 | rejected | editorial | Agreement |
lc-pwalmsley-1 : Document or Element Node | agreed | editorial | Agreement |
lc-pwalmsley-2 : "node-set" should be "sequence" | agreed | editorial | Agreement |
lc-pwalmsley-3 : QualifiedLocalElements | rejected | editorial | Agreement |
lc-pwalmsley-4 : UnqualifiedLocalElements | rejected | editorial | Agreement |
lc-pwalmsley-5 : ElementFinal | accepted | editorial | Agreement |
lc-pwalmsley-6 : ImportTypesNamespace | rejected | editorial | Agreement |
lc-pwalmsley-7 : GlobalElement and GlobalAttribute | accepted | editorial | Agreement |
lc-pwalmsley-8 : @type colon | rejected | editorial | Agreement |
lc-pwalmsley-9 : GlobalElementSequence | accepted | editorial | Agreement |
lc-pwalmsley-10 : ElementMaxOccursFinite | accepted | editorial | Agreement |
lc-pwalmsley-11 : ElementEmptySequence @name | accepted | editorial | Agreement |
lc-pwalmsley-12 : ElementEmptySequence not(node()) | accepted | editorial | Agreement |
lc-pwalmsley-13 : ElementEmptyComplexType @name | accepted | editorial | Agreement |
lc-pwalmsley-14 : ElementEmptyComplexType not(node()) | accepted | editorial | Agreement |
lc-pwalmsley-15 : Global SimpleType Declarations | accepted | editorial | Agreement |
lc-pwalmsley-16 : GlobalSimpleType and GlobalComplexType | accepted | editorial | Agreement |
lc-pwalmsley-17 : StringEnumerationType | rejected | editorial | Agreement |
lc-Microsoft-1 : Support for Attributes | no decision (raised) | proposal | |
lc-Microsoft-2 : Element References | no decision (raised) | proposal | |
lc-Microsoft-3 : Nested Sequences and sequences other than minOccurs=maxOccurs=1 | no decision (raised) | proposal | |
lc-Microsoft-4 : schemaLocation | no decision (raised) | proposal | |
lc-Microsoft-5 : maxOccurs=finite | no decision (raised) | proposal | |
lc-Microsoft-6 : Null enumerations | no decision (raised) | proposal | |
lc-Microsoft-7 : Mixing elements maxOccurs=1 and maxOccurs>1 in the same sequence, or allowing more than one maxOccurs>1 element | no decision (raised) | proposal | |
lc-Microsoft-8 : Mixing elements maxOccurs=1 and maxOccurs>1 in the same inheritance chain | no decision (raised) | proposal | |
lc-i18n-1 : BOM link to Unicode FAQ | accepted | editorial | No response to reviewer |
lc-i18n-2 : Working with Time Zones | no decision (raised) | editorial | |
lc-i18n-3 : language type to reference BCP47 | no decision (raised) | editorial | |
lc-psd-2 : xs:date and xs:time patterns not well suported by implementations | no decision (raised) | proposal | |
haas-1 : Difficulty to read patterns as expressed with XPath 2.0 | no decision (raised) | proposal | |
lc-xsd-1 : References to concepts and terminology from XSD need to be made more precise | agreed | editorial | No reply from reviewer |
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
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?
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?
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.
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
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.
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.
Pattern 2.2.1 DocumentationElement. Listing <xs:annotation> twice (in context and out) looks like a bug in the example generation code ;-).
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.
Appendix C why is R2800 not grouped with R2112? They seem to be introduced the same way.
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
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.
Everywhere it says "node-set" it should say "sequence".
It might be more illustrative to show an example of a locally declared element in the schema and have the instance element be prefixed
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
Only global elements can validly have the @final attribute, so the path could start with ./xs:element instead of .//xs:element
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]."
The "@name and " is redundant since all global element/attribute declarations have to have name attributes
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 AttributeReference
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 ComplexTypeSequence
Could be simplified: .//xs:element[@maxOccurs != ('0','1','unbounded')]
The [@name] is redundant because an xs:element without a name could never have a complexType child
Instead of not(node()) which would return true even if there was <sequence> </sequence>, should it be not(*) or not (* except xs:annotation)
The [@name] is redundant because an xs:element without a name could never have a complexType child
Instead of not(node()) which would return true even if there was <complexType> </complexType>, should it be not(*) or not (* except xs:annotation)
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.)
[@name] is redundant since top-level complex types always have names
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>
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.
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.
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.
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.
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.
Could you please clarify the purpose of pattern 2.11.3?
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.
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..
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.
various 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.
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).
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"
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.
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.
Last update: $Date: 2008/07/23 16:51:42 $
This page was generated as part of the Extensible Issue Tracking System (ExIT)
Copyright © 2003, 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.