W3CArchitecture Domain XML | XML Schema

XML Schema

Software-developer Feedback Form

This form is intended to make it easier for software developers to provide feedback on the W3C XML Schema Candidate Recommendation (Part 0, Part 1, Part 2) to the W3C XML Schema Working Group.

A separate form for schema authors is also available.

And of course you can also provide feedback by sending email to the XML Schema comments list at www-xml-schema-comments@w3.org.

Comments received via email or by way of this form on or before 29 December 2000 will be tracked by the XML Schema WG as part of our comment-resolution process. For comments received after that date, we will track them and and respond to them if we can, but we may or may not be able to do so, and make no promises.


Background information

Email address (required)
Name (optional)
Organization (optional)
Available for public use? as commercial product · as free / non-commercial package
closed source · open source ·
available now · available soon · will be available eventually · not publicly available
URI for downloading, ordering, or further information
Type of implementation Schema reader (i.e. reads/parses schema documents)
Schema checker (i.e. assesses schema documents for conformance to the spec)
Document checker (i.e. assesses documents for schema-validity)
Schema-document editor
Schema-guided XML editor
Other (please describe below)
Form of output Error and warning messages only
Internal / binary representation of post-schema-validation infoset
XML serialization of PSV infoset
Other (describe)
Description of software
State of implementation planned
under construction, not yet released
released, but still being worked on
completed, no longer being worked on
N.B. in the questions below, please describe the current state of the implementation, not the planned complete state. If there are things you plan never to implement, please indicate them at an appropriate point.

If you have developed a collection of test data for your implementation and are willing to share it with others, we encourage you to make it available on the Web and post information about it to xmlschema-dev@w3.org and to allow us to list it on our sample-data page. If you are unable to make your test cases available on your organization's Web site, but are willing to share them, contact [whom?] to discuss the possibility of hosting them on another site.


Feature coverage / utility

Part 1 (Structures)

Which features of XML Schema have you implemented, and how complete is the implementation? If you have comments on implementation issues, feel free to make them in the text fields provided. We are particularly interested to know, for any feature not fully supported, whether implementation difficulties are the reason for the lack of full support, and what changes to the design would (in your view) make the feature sufficiently easy to implement. If you would object strongly to the removal of any particular feature, that would be worth noting, too. (Otherwise, we'll only hear from people who would like to delete the feature.)

Full Partial None Feature
Post-schema-validation infoset contributions
Comments:
Creation of schema components from schema documents in the XML transfer syntax defined in the spec
Comments:
Validation of complex type derivation by restriction (in particular, checking that the derived type is in fact a legal restriction)
Checking that content models are deterministic
Comments:
Validation of the content of elements in document instances against the corresponding complex types. In particular, does your implementation support
  • yes · no · substitution groups?
  • yes · no · use of complex types derived from the one declared (via xsi:type in instance)?
Comments:
Wildcards (all flavors? some? which?)
Comments:
Identity and uniqueness constraints
Comments:
Schema composition: include (with matching target NS, with unspecified target NS), import, redefine
Comments:

The xsi:schemaLocation attribute is formally a hint. Does your implementation follow that hint
always? sometimes? never?

Do you allow users to override the hint (e.g. by specifying what schema to use for a given namespace, when they invoke your software)?
yes · no · Comments:

Do you allow users to specify that validation must be strict instead of lax?
yes · no · Comments:

Do you allow the user to require that the root element of the document be of a particular element type or of a particular complex type?
yes · no · Comments:

Part 2: Datatypes

Which parts of Part 2 of the XML Schema spec (simple types) does your implementation fully or partially support?

Full Partial None Feature
Validation of simple type derivation by restriction (in particular, checking that the derived type is in fact a legal restriction)
Comments:
Validation of literal values in the document instance (i.e. checking that they are legal values for their declared type)
Comments:

Which simple types does your implementation support? all · some · none

If you support some but not all simple types, which do you support?

If you provide partial but not full support, what kind of support do you provide, and what do you not do that a full implementation would do? Did you encounter implementation difficulties in this area?

Which facets does your implementation support? all · some · none

If you support some but not all facets, which do you support?

If you provide partial but not full support for these facets, what kind of support do you provide, and what do you not do that a full implementation would do? Did you encounter implementation difficulties in this area?

Do you support derivation of simple types by

If you provide partial but not full support for these forms of derivation, what kind of support do you provide, and what do you not do that a full implementation would do? Did you encounter implementation difficulties in this area?


Priority feedback requests

On a number of points, the XML Schema spec requests particular feedback from implementors and users. Your feedback on these questions will have direct effects on the WG's decisions regarding revision of the relevant features of XML Schema.

Part 1 (Structures)

xsi:null

Does the xsi:null feature provide useful functionality? Do you have requirements to support null values in the area in which you expect your software to be deployed? If so, does the xsi:null feature provide what you need? Would you have a problem if XML Schema provided no mechanism for document authors / data sources to provide explicit null values?

Does the xsi:null feature create any implementation problems for you?

Setting schema-level defaults

A number of the attributes on the <schema> element provide defaults for attributes on subordinate elements. To wit:

This allows setting values for attributes we judge likely to have the same value across a whole schema document in only one place. It does constitute a kind of minimisation, and does not provide any new semantics. Is it a good thing, or not a good thing, to allow the default value to vary from schema to schema? Is this a good way to set such schema-level defaults? These default-setting attributes themselves have default values; are they the correct values?

Local element declarations

The provision of local element declarations is in part intended to simplify mapping between programming language and database structures where locally scoped name-type bindings are commonplace. It is a departure from XML 1.0 DTDs, in which the name-type binding for elements (but not for attributes) is constant across a document. Is it a good thing or not a good thing to provide local element declarations? Does it in fact simplify mappings as intended?

Order of content model and attribute declarations

Complex types which have both a content model and attributes must have them in that order. Is it a good idea to require a fixed order? (It is sometimes suggested that a fixed order simplifies implementations. Is this true or false, in your case?) If a fixed order is required, should it be this one (content model then attributes), or should it be the other way round (attributes then content model)?

Multiple inclusions/imports/redefinitions

Sections 6.2.1, 6.2.2, and 6.2.3 each end with a note about multiple inclusion/redefinition/importing of other schema documents. The space of possibilities here is very large, particularly once nesting is considered: we solicit feedback on ease of implementation, and any interoperability issues which arise.

Redefine

In an effort to provide some support for evolution and versioning, it is possible to incorporate components corresponding to a schema document with modifications. The modifications have a pervasive impact, that is, only the redefined components are used, even when referenced from other incorporated components, whether redefined themselves or not.

This facility is very powerful, perhaps too powerful. Reports of implementation experience, in terms of useability for particular purposes, of the constraints on redefinition imposed in the spec and of implementation difficulty, would be very welcome.

Part 2 (Datatypes)

Minimal level of support for decimals digits

All minimally conforming processors must support decimal numbers with a minimum of 18 decimal digits (i.e., with a precision of 18). However, minimally conforming processors may set an application-defined limit on the maximum number of decimal digits they are prepared to support, in which case that application-defined maximum number must be clearly documented.

As in all such cases, the minimum number of decimal digits that all minimally conforming processors must support is too small for some applications and, perhaps, too large for others. We welcome further input from implementors whether the minimum value of 18 is acceptable.

Order on timeDuration

Note that the order-relation on timeDuration is defined for some pairs of durations but not for all pairs. In such cases the the order relation in said to be indeterminate. For example, while P1M25D > P50D and P1M10D < P50 the order relation between P1M20D and P50D is indeterminate.

The complexity of real world durations of time introduces difficulties into any design that attempts to support them. The XML Schema Working Group acknowledges the undesirability of an order-relation that specifies a partial (as opposed to a total) order; however, it has found no other solution that garnered consensus. Therefore, the XML Schema Working Group welcomes feedback from implementors and schema authors on alternative designs. Specifically, we are interested in knowing whether timeDuration needs to be ordered at all and in hearing how other implemented systems which provide a total order for durations of time have defined that total order.

Interoperability of date/time types

While recurringDuration is capable of serving as the base type of datatypes used in many different date and time related applications beyond those supplied by its use as the base type of the built-in datatypes derived from it, recurringDuration is not intended as a general-purpose solution to calendaring and scheduling applications.

The XML Schema Working Group is particularly interested in feedback from implementors and schema authors as to how timeDuration, recurringDuration and the other date and time related datatypes derived from recurringDuration interoperate with other date and time related systems.

Non-URI characters and URI references

URI References require certain ASCII characters and all non-ASCII characters be hex encoded, sometimes called URI-escaping (see Section 2 of [RFC 2396], as amended by Section 3 of [RFC 2732]). Therefore, schema authors need to exercise caution in the use of uriReference. Specifically, schema authors should avoid uriReference in cases where literals should be allowed to directly contain characters that [RFC 2396], as amended by [RFC 2732], require to be hex encoded.

There is ongoing discussion about how to treat URI References that might contain non-ASCII characters. It is extremely important that all W3C specifications that deal with such URI References (at least this specification, [Character Model], [XML 1.0 Recommendation (Second Edition)] and [XPointer], probably others) be aligned; however, it is not clear how best to achieve that alignment with this specification. In addition to the current design, where both the lexical space and value space of uriReference are considered to be hex encoded, there are at least 3 alternative designs that could be considered: 1) have 2 types, the current type and another type (not strictly speaking, a URI Reference) where both the lexical space and value space where allowed to contain non-ASCII characters; 2) a single type whose lexical space is allowed to contain non-ASCII characters, but whose value space was the set of hex-encoded literals; 3) a single type whose lexical space was hex-encoded, but whose value space was allowed to contain non-ASCII characters (i.e., the set of hex-decoded literals). The XML Schema Working Group welcomes feedback from implementors and schema authors on how to further harmonize the effected specifications; in particular, we seek advice on which of the above alternatives (or some other alternative not yet considered) is most desirable. Changes resulting from such further harmonization might result in additional changes to the XML Schema Language in cases where uriReference in used (e.g., xsi:schemaLocation in [XML Schema Part 1: Structures]).

Regular expression and diacritics

The regular expression language defined here does not attempt to provide a general solution to "regular expressions" over [Unicode3] strings. In particular, it does not easily provide for matching sequences of base characters and combining marks. The language is targeted at support of "Level 1" features as defined in [Unicode Regular Expression Guidelines]. It is hoped that future versions of this specification will provide support for "Level 2" features.

Whitespace in regular expressions

Future versions of this specification might allow non-significant white space embedded within a regular expression. The XML Schema Working Group welcomes feedback from implementors and schema authors on the advisability of including such white space.


Other

Any other comments you would like to make are welcome. Make them here, or post them to the XML Schema public comments list.

One last question. Any suggestions for improving this form? In particular: are there questions we ought to be asking you, as an implementor, but have not asked?


$Id: xmlschema-feedback-sw.html,v 1.5 2000/12/16 03:40:27 cmsmcq Exp $