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.

Transition history

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

Transition history

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.

Transition history

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.

Transition history

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.

Transition history

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.

Transition history

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.

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.

Transition history

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

Transition history

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"

Transition history

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.

Transition history

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.

Transition history

Acknowledgment cycle

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

Acknowledgment cycle

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?

Acknowledgment cycle

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.

Acknowledgment cycle

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

Acknowledgment cycle

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

Acknowledgment cycle

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.

Acknowledgment cycle

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?

Acknowledgment cycle

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.

Transition history

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

Acknowledgment cycle

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.

Transition history

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.

Acknowledgment cycle

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.

Transition history

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

Acknowledgment cycle

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

Acknowledgment cycle

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