W3C Basic XML Schema Patterns for Databinding Last Call Issues List

Inside: Issue summary | State description | Decision cycle description | Issue details (Validate data)

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.

Status of this Document

being used to track Last Call Issues for the Basic Patterns document.

Issue summary (39 issues)

Reformat summary with options:
Expert mode options
Hide columns:
Hide issues by type:
Hide issues by state:
Hide issues by acknowledgment:

Other views: types | states | concerning | reviewers | open actions

Changes between dates (YYYY-MM-DD) and [Optional]

For maintainers: new issue data | new issues list data

Color key: error warning note

Id:Title StateTypeAck.
lc-erh-1 : typo "casue"agreededitorialNo reply from reviewer
lc-drkm-1 : XPath 2.0 and node-set ?agreededitorialNo reply from reviewer
lc-psd-1 : WS-I Basic Profile compliant schema importagreedproposalAgreement
lc-jmarsh-1 : XPath Expressions Too Complex?declinededitorialAgreement
lc-jmarsh-2 : Schema Version AttributedeclinededitorialAgreement
lc-jmarsh-3 : Duplicate ListingagreededitorialAgreement
lc-jmarsh-4 : Value of @mixed="false" etcrejectededitorialAgreement
lc-jmarsh-5 : Grouping of R2800 and R2112rejectededitorialAgreement
lc-pwalmsley-1 : Document or Element NodeagreededitorialAgreement
lc-pwalmsley-2 : "node-set" should be "sequence"agreededitorialAgreement
lc-pwalmsley-3 : QualifiedLocalElementsrejectededitorialAgreement
lc-pwalmsley-4 : UnqualifiedLocalElementsrejectededitorialAgreement
lc-pwalmsley-5 : ElementFinalacceptededitorialAgreement
lc-pwalmsley-6 : ImportTypesNamespacerejectededitorialAgreement
lc-pwalmsley-7 : GlobalElement and GlobalAttributeacceptededitorialAgreement
lc-pwalmsley-8 : @type colonrejectededitorialAgreement
lc-pwalmsley-9 : GlobalElementSequenceacceptededitorialAgreement
lc-pwalmsley-10 : ElementMaxOccursFiniteacceptededitorialAgreement
lc-pwalmsley-11 : ElementEmptySequence @nameacceptededitorialAgreement
lc-pwalmsley-12 : ElementEmptySequence not(node())acceptededitorialAgreement
lc-pwalmsley-13 : ElementEmptyComplexType @nameacceptededitorialAgreement
lc-pwalmsley-14 : ElementEmptyComplexType not(node())acceptededitorialAgreement
lc-pwalmsley-15 : Global SimpleType DeclarationsacceptededitorialAgreement
lc-pwalmsley-16 : GlobalSimpleType and GlobalComplexTypeacceptededitorialAgreement
lc-pwalmsley-17 : StringEnumerationTyperejectededitorialAgreement
lc-Microsoft-1 : Support for Attributesno decision
(raised)
proposal
lc-Microsoft-2 : Element Referencesno decision
(raised)
proposal
lc-Microsoft-3 : Nested Sequences and sequences other than minOccurs=maxOccurs=1no decision
(raised)
proposal
lc-Microsoft-4 : schemaLocationno decision
(raised)
proposal
lc-Microsoft-5 : maxOccurs=finiteno decision
(raised)
proposal
lc-Microsoft-6 : Null enumerationsno decision
(raised)
proposal
lc-Microsoft-7 : Mixing elements maxOccurs=1 and maxOccurs>1 in the same sequence, or allowing more than one maxOccurs>1 elementno decision
(raised)
proposal
lc-Microsoft-8 : Mixing elements maxOccurs=1 and maxOccurs>1 in the same inheritance chainno decision
(raised)
proposal
lc-i18n-1 : BOM link to Unicode FAQacceptededitorialNo response to reviewer
lc-i18n-2 : Working with Time Zonesno decision
(raised)
editorial
lc-i18n-3 : language type to reference BCP47no decision
(raised)
editorial
lc-psd-2 : xs:date and xs:time patterns not well suported by implementationsno decision
(raised)
proposal
haas-1 : Difficulty to read patterns as expressed with XPath 2.0no decision
(raised)
proposal
lc-xsd-1 : References to concepts and terminology from XSD need to be made more preciseagreededitorialNo reply from reviewer

State description

Decision cycle description

Issue details

lc-erh-1: typo "casue" [link to this issue]

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

Transition history

raised on 30 Nov 2006 by Eliotte Harold (elharo@metalab.unc.edu)
agreed on 13 Feb 2007

fixed typeo.

Acknowledgment cycle
announced by group on 20 Mar 2007

lc-drkm-1: XPath 2.0 and node-set ? [link to this issue]

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?

Transition history

raised on 4 Dec 2006 by Florent Georges (darkman_spam@yahoo.fr)
agreed on 13 Feb 2007

accepted proposed terminology change.

Acknowledgment cycle
announced by group on 22 Jul 2008

lc-psd-1: WS-I Basic Profile compliant schema import [link to this issue]

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?

Transition history

raised on 12 Dec 2006 by Paul Downey (paul.downey@bt.com)
agreed on 13 Feb 2007

accepted proposed terminology change.

Acknowledgment cycle
announced by group on 13 Feb 2007
agreement by reviewer on 13 Feb 2007

lc-jmarsh-1: XPath Expressions Too Complex? [link to this issue]

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

raised on 4 Jan 2007 by Jonathan Marsh (jonathan@wso2.com)
declined on 13 Feb 2007

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
announced by group on 22 Jul 2008
agreement by reviewer on 23 Jul 2008

lc-jmarsh-2: Schema Version Attribute [link to this issue]

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

raised on 4 Jan 2007 by Jonathan Marsh (jonathan@wso2.com)
declined on 13 Feb 2007

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
announced by group on 22 Jul 2008
agreement by reviewer on 23 Jul 2008

lc-jmarsh-3: Duplicate Listing [link to this issue]

Pattern 2.2.1 DocumentationElement.  Listing <xs:annotation> twice
(in context and out) looks like a bug in the example generation code ;-).

Transition history

raised on 4 Jan 2007 by Jonathan Marsh (jonathan@wso2.com)
agreed on 13 Feb 2007

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

Acknowledgment cycle
announced by group on 22 Jul 2008
agreement by reviewer on 23 Jul 2008

lc-jmarsh-4: Value of @mixed="false" etc [link to this issue]

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

raised on 4 Jan 2007 by Jonathan Marsh (jonathan@wso2.com)
rejected on 13 Feb 2007

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

Acknowledgment cycle
announced by group on 22 Jul 2008
agreement by reviewer on 23 Jul 2008

lc-jmarsh-5: Grouping of R2800 and R2112 [link to this issue]

Appendix C why is R2800 not grouped with R2112?  They seem to be introduced the same way.

Transition history

raised on 4 Jan 2007 by Jonathan Marsh (jonathan@wso2.com)
rejected on 13 Feb 2007

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
announced by group on 22 Jul 2008
agreement by reviewer on 23 Jul 2008

lc-pwalmsley-1: Document or Element Node [link to this issue]

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.

Transition history

raised on 15 Jan 2007 by Priscilla Walmsley (pwalmsley@datypic.com)
agreed on 13 Feb 2007

Accepted suggested terminology

Acknowledgment cycle
announced by group on 13 Feb 2007
agreement by reviewer on 13 Feb 2007

lc-pwalmsley-2: "node-set" should be "sequence" [link to this issue]

Everywhere it says "node-set" it should say "sequence".

Transition history

raised on 15 Jan 2007 by Priscilla Walmsley (pwalmsley@datypic.com)
agreed on 13 Feb 2007

Accepted suggested terminology

Acknowledgment cycle
announced by group on 13 Feb 2007
agreement by reviewer on 13 Feb 2007

lc-pwalmsley-3: QualifiedLocalElements [link to this issue]

It might be more illustrative to show an example of a locally declared
element in the schema and have the instance element be prefixed

Transition history

raised on 15 Jan 2007 by Priscilla Walmsley (pwalmsley@datypic.com)
rejected on 13 Feb 2007

Example doesn't have elements.

Acknowledgment cycle
announced by group on 13 Feb 2007
agreement by reviewer on 13 Feb 2007

lc-pwalmsley-4: UnqualifiedLocalElements [link to this issue]

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

Transition history

raised on 15 Jan 2007 by Priscilla Walmsley (pwalmsley@datypic.com)
rejected on 13 Feb 2007

as for lc-pwalmsley-3

Acknowledgment cycle
announced by group on 13 Feb 2007
agreement by reviewer on 13 Feb 2007

lc-pwalmsley-5: ElementFinal [link to this issue]

Only global elements can validly have the @final attribute, so the path
could start with ./xs:element instead of .//xs:element

Transition history

raised on 15 Jan 2007 by Priscilla Walmsley (pwalmsley@datypic.com)
accepted on 13 Feb 2007

accepted modification to ElementFinal pattern

Acknowledgment cycle
announced by group on 13 Feb 2007
agreement by reviewer on 13 Feb 2007

lc-pwalmsley-6: ImportTypesNamespace [link to this issue]

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

Transition history

raised on 15 Jan 2007 by Priscilla Walmsley (pwalmsley@datypic.com)
rejected on 13 Feb 2007

captures a common pattern used within WSDL documents

Acknowledgment cycle
announced by group on 13 Feb 2007
agreement by reviewer on 13 Feb 2007

lc-pwalmsley-7: GlobalElement and GlobalAttribute [link to this issue]

The "@name and " is redundant since all global element/attribute
declarations have to have name attributes

Transition history

raised on 15 Jan 2007 by Priscilla Walmsley (pwalmsley@datypic.com)
accepted on 13 Feb 2007

simplified pattern XPaths as suggested

Acknowledgment cycle
announced by group on 13 Feb 2007
agreement by reviewer on 13 Feb 2007

lc-pwalmsley-8: @type colon [link to this issue]

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

Transition history

raised on 15 Jan 2007 by Priscilla Walmsley (pwalmsley@datypic.com)
rejected on 13 Feb 2007

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

Acknowledgment cycle
announced by group on 13 Feb 2007
agreement by reviewer on 13 Feb 2007

lc-pwalmsley-9: GlobalElementSequence [link to this issue]

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

Transition history

raised on 15 Jan 2007 by Priscilla Walmsley (pwalmsley@datypic.com)
accepted on 13 Feb 2007

accepted proposed change

Acknowledgment cycle
announced by group on 13 Feb 2007
agreement by reviewer on 13 Feb 2007

lc-pwalmsley-10: ElementMaxOccursFinite [link to this issue]

Could be simplified: .//xs:element[@maxOccurs != ('0','1','unbounded')]

Transition history

raised on 15 Jan 2007 by Priscilla Walmsley (pwalmsley@datypic.com)
accepted on 13 Feb 2007

accepted proposed change

Acknowledgment cycle
announced by group on 13 Feb 2007
agreement by reviewer on 13 Feb 2007

lc-pwalmsley-11: ElementEmptySequence @name [link to this issue]

The [@name] is redundant because an xs:element without a name could never
have a complexType child
         

Transition history

raised on 15 Jan 2007 by Priscilla Walmsley (pwalmsley@datypic.com)
accepted on 13 Feb 2007

accepted proposed change

Acknowledgment cycle
announced by group on 13 Feb 2007
agreement by reviewer on 13 Feb 2007

lc-pwalmsley-12: ElementEmptySequence not(node()) [link to this issue]

Instead of not(node()) which would return true even if there was
<sequence> </sequence>, should it be not(*) or not (* except xs:annotation)

Transition history

raised on 15 Jan 2007 by Priscilla Walmsley (pwalmsley@datypic.com)
accepted on 13 Feb 2007

accepted proposed change

Acknowledgment cycle
announced by group on 13 Feb 2007
agreement by reviewer on 13 Feb 2007

lc-pwalmsley-13: ElementEmptyComplexType @name [link to this issue]

The [@name] is redundant because an xs:element without a name could never
have a complexType child

Transition history

raised on 15 Jan 2007 by Priscilla Walmsley (pwalmsley@datypic.com)
accepted on 13 Feb 2007

accepted proposed change

Acknowledgment cycle
announced by group on 13 Feb 2007
agreement by reviewer on 13 Feb 2007

lc-pwalmsley-14: ElementEmptyComplexType not(node()) [link to this issue]

Instead of not(node()) which would return true even if there was
<complexType> </complexType>, should it be not(*) or not (* except
xs:annotation)

Transition history

raised on 15 Jan 2007 by Priscilla Walmsley (pwalmsley@datypic.com)
accepted on 13 Feb 2007

accepted proposed change

Acknowledgment cycle
announced by group on 13 Feb 2007
agreement by reviewer on 13 Feb 2007

lc-pwalmsley-15: Global SimpleType Declarations [link to this issue]

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

Transition history

raised on 15 Jan 2007 by Priscilla Walmsley (pwalmsley@datypic.com)
accepted on 13 Feb 2007

accepted proposed change

Acknowledgment cycle
announced by group on 13 Feb 2007
agreement by reviewer on 13 Feb 2007

lc-pwalmsley-16: GlobalSimpleType and GlobalComplexType [link to this issue]

[@name] is redundant since top-level complex types always have names

Transition history

raised on 15 Jan 2007 by Priscilla Walmsley (pwalmsley@datypic.com)
accepted on 13 Feb 2007

accepted proposed change

Acknowledgment cycle
announced by group on 13 Feb 2007
agreement by reviewer on 13 Feb 2007

lc-pwalmsley-17: StringEnumerationType [link to this issue]

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> 

Transition history

raised on 15 Jan 2007 by Priscilla Walmsley (pwalmsley@datypic.com)
rejected on 13 Feb 2007

withdraw that one, cathcall picks it up

Acknowledgment cycle
announced by group on 13 Feb 2007
agreement by reviewer on 13 Feb 2007

lc-Microsoft-1: Support for Attributes [link to this issue]

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

raised on 15 Jan 2007 by Eugene Osovetsky (Eugene.Osovetsky@microsoft.com)

lc-Microsoft-2: Element References [link to this issue]

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

raised on 15 Jan 2007 by Eugene Osovetsky (Eugene.Osovetsky@microsoft.com)

lc-Microsoft-3: Nested Sequences and sequences other than minOccurs=maxOccurs=1 [link to this issue]

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

raised on 15 Jan 2007 by Eugene Osovetsky (Eugene.Osovetsky@microsoft.com)

lc-Microsoft-4: schemaLocation [link to this issue]

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

raised on 15 Jan 2007 by Eugene Osovetsky (Eugene.Osovetsky@microsoft.com)

lc-Microsoft-5: maxOccurs=finite [link to this issue]

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.

Transition history

raised on 15 Jan 2007 by Eugene Osovetsky (Eugene.Osovetsky@microsoft.com)

lc-Microsoft-6: Null enumerations [link to this issue]

Could you please clarify the purpose of pattern 2.11.3?

Transition history

raised on 15 Jan 2007 by Eugene Osovetsky (Eugene.Osovetsky@microsoft.com)

lc-Microsoft-7: Mixing elements maxOccurs=1 and maxOccurs>1 in the same sequence, or allowing more than one maxOccurs>1 element [link to this issue]

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

raised on 15 Jan 2007 by Eugene Osovetsky (Eugene.Osovetsky@microsoft.com)

lc-Microsoft-8: Mixing elements maxOccurs=1 and maxOccurs>1 in the same inheritance chain [link to this issue]

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

raised on 15 Jan 2007 by Eugene Osovetsky (Eugene.Osovetsky@microsoft.com)

lc-i18n-1: BOM link to Unicode FAQ [link to this issue]

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

raised on 15 Jan 2007 by Felix Sasaki (fsasaki@w3.org)
accepted on 13 Feb 2007
Acknowledgment cycle
Not started

lc-i18n-2: Working with Time Zones [link to this issue]

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

raised on 15 Jan 2007 by Felix Sasaki (fsasaki@w3.org)

lc-i18n-3: language type to reference BCP47 [link to this issue]

 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

raised on 15 Jan 2007 by Felix Sasaki (fsasaki@w3.org)

lc-psd-2: xs:date and xs:time patterns not well suported by implementations [link to this issue]

 
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

raised on 20 Apr 2007 by Paul Downey (paul.downey@bt.com)

haas-1: Difficulty to read patterns as expressed with XPath 2.0 [link to this issue]

 
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

raised on 20 Apr 2007 by Hugo Haas (hugo@yahoo-inc.com)

lc-xsd-1: References to concepts and terminology from XSD need to be made more precise [link to this issue]

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.

Transition history

raised on 15 Feb 2008 by Noah Mendelsohn (noah_mendelsohn@us.ibm.com)
agreed on 11 Mar 2008

Accepted suggested terminology.

Acknowledgment cycle
announced by group on 22 Jul 2008

Maintained by W3C XML Schema Patterns for Databinding.

Last update: $Date: 2008/07/23 16:51:42 $


This page was generated as part of the Extensible Issue Tracking System (ExIT)