W3C XML Schema Questionnaire

Jonathan Robie
Software AG

E-mail: Jonathan.Robie@SoftwareAG-USA.com

Introduction

This survey attempts to measure the response of the XML develo9per community to the W3C XML Schema specification. At the time of the survey, XML.com had just published an article about the response of the developer community to the W3C XML Schema Specification (Last Word on Last Call). Among other things, this article claimed:

While some implementers outside the W3C process do not see impediments in the last call draft, from my brief survey, these folks tend not to be looking to use the new features of schema or to write the reference implementations. For them, the schema draft represents DTD-in-XML-syntax with datatypes, and if the rest of it has issues, they donâ?™t care. Among the others, who also support the W3C effort, there are those who wish for some changes. The most-desired changes are to reduce the feature set, with an eye toward reducing complexity of design, and to do a major rewrite so that simple things are not rendered hard, and hard things not made harder. Among those who take issue with the draft, the most favored outcome is universally viewed unlikely to happen: release of the data types part of the specification along with a DTD for schemas replicating DTD functionality, and more time to sort the rest of it out.

When I discussed this article with other members of the W3C XML Schema Working Group, I found that we had a wide range of perceptions of how potential users felt. In response, I posted a questionnaire to a number of Working Groups along with the following text:

As a member of the Schema WG, I'm still deciding how to vote on moving Schema to CR. I would be interested in hearing whether the members of this mailing list agree with the conclusions in Liora's article. I am not doing this in any official capacity, I am doing this because I want to know.

I hope that this survey not only my personal voting on the Schema Working Group, but will also prove helpful for other Working Group members. Naturally, this survey is only one source of information for those who wish to see how the XML community is receiving the XML Schema specifications, and these results should be compared to other indicators. Any source of data is also subject to more than one interpretation; since the raw data is available in this report, readers are free to do their own analysis of the data.

My conclusions are presented in the first section, "Analysis of Results". The data from the surveys is presented in the second section, "Cumulated Results", and an appendix contains the original questionnaire.

Analysis of Results

This section presents the survey results and the conclusions that I feel can be drawn from them.

Who Responded?

Questionnaires were sent to the following mailing lists:

  1. W3C XML Schema Interest Group (w3c-xml-schema-ig@w3.org)
  2. XML Developers (xml-dev@lists.xml.org)
  3. XML/EDI Group (xmledi-group@disa.org)

The questionnaire started with a section that asked respondents to describe themselves. Most respondents said that they play several roles. Out of 31 respondents, 22 classified themselves as software architects, 17 as programmers, and 13 as consultants. Roughly a third classified themselves as web developer (10), XML content developer (10), or database developer (7). Two respondents classified themselves as researchers, one as an engineering manager for a large team, and one as a data standards architect. One respondent classified himself as a member of the Schema Working Group; in addition, several respondents who did not choose this classification are members of the Working Group.

A striking proportion of the people who responded are well known in the XML community, either as speakers at various XML events, members of W3C Working Groups, or authors. Several respondents requested anonymity so that they could respond frankly - some of these requests are shown in the comments in this report, many more requests were made in separate emails.

Roughly one third of the respondents (11) are writing software based on schema, and almost two thirds (18) have written schemas based on the Working Drafts. About one third (13) have also written schemas in other schema languages. All but two said that they had read the Working Drafts. Roughly two thirds (20) had used schema parsers.

Yes, We Want It!

The vast majority of respondents want something like Schema. Only one respondent did not need anything beyond DTDs. Almost one third (8) would like to see Schema become a recommendation in its current form. One third (10) said they like it, but it needs some changes. One third (10) said they need something like schema, but it needs serious work.

Just over half (16) said that they or their companies would write software based on schema, and almost exactly the same number (17) said that they would depend on software based on Schema. Almost two thirds (20) said they would need to write schemas. The comments people made often stressed that schema is very important to them.

Furthermore, there was broad support for most features found in Schema. However, there was significant support for postponing several features to a future version of Schema.

Features

One half of respondents (16) felt that Schema contains features they are unlikely to use. The other half felt either that Schema contained all the features they would like (10) or that they would prefer more features (5).

The vast majority of respondents wanted an XML-based notation for schemas (26) and data types (28). Roughly two thirds wanted attribute group definitions (20), schema composition (18), and the use of schemaloc to associate schemas with instance documents. Almost as many wanted identity constraints (17). None of the other features were desired by more than half of the group, but every remaining feature was wanted by at least one third of the group, including refinement (13), element equivalence classes (14).

However, there were also a number of respondents who felt that some of these features should be postponed, and for some features there was a significant number who felt they were unnecessary. Of the 14 people who said they wanted element equivalence classes, 7 said that it should be put off for Level 2. Taking that into consideration, 7 felt that this should be done in Level 1, and 13 felt it should be done in Level 2. Altogether, 20 people wanted this functionality at some point. But since 6 respondents found it unnecessary and 10 wanted to put it off for Level 2, a little over half do not feel it is needed in Level 1.

Refinement received clearly mixed reviews. 13 said they wanted refinement, but 3 of these said they thought we should put it off for Level 2. Taking this into account, 10 people thought it should be done in Level 1, and 10 thought it should be done in Level 2. There were 8 respondents who found it unnecessary. Altogether, 18 did not feel it was necessary for Level 1.

Nulls and nullability received 8 votes from those who wanted it and did not want to postpone it for a future level, 8 found it unnecessary, and 10 wanted to postpone it to a future level.

Identity constraints received 14 votes from those who wanted it and did not want to postpone it for a future level, 6 found it unnecessary, and 8 wanted to postpone it to a future level.

Every feature was found desireable by at least half of the group, and several individuals acknowledged that features they do not need personally might be useful for others. My reading of individual voting patterns and comments indicates that the main reason for wanting to put off some features was to ensure that they are well designed.

Readability

Readability seen as a significant problem for the Structures specification. One half of all respondents (15) agreed with the statement that "Readability seriously interferes with the purpose of this document. This really needs to be rewritten before it is released." No respondent found it "well written and helpful". About one third felt either that it was either usable with some shortcomings (5) or that it does the job (5). Several comments stated that respondents had tried to read structures but had been unable to do so. Almost two thirds (18) found that this specification was not readable compared to other technical specifications. Comments on the structures specification showed a level of frustration. The following comments are drawn from different individuals: "Don't know, since I cannot read Part 1", "I don't really know (whether the important details are spelled out). It's hard for me to find them.", "The complexity of the document is an indication that certain things aren't well designed. Removal of certain features and refinement of schema for schemas could remove a whole lot of the complexity." Those actually developing software tended to feel that the important details actually are spelled out, but hard to find and hard to understand. One individual writing such software said, "Although this document was extremely difficult to digest, after re-reading it about 5 times I finally feel that I have a good handle on how things work...I don't mind complex documents, but the language obscures the meaning in these sections." Another person writing schema-based software said, "A lot of detail is there, but sometimes there seems to be a framework guiding the spec but it is mysterious to me. Perhaps it is a reflection of the theoretical immaturity of this area of work, but it would be nice to have more answers to 'why', and not just what and how." Another developer had to admit defeat (though he did not specify the structures specification), saying "I have *attempted* to read the WDs - I have retreated to experimenting against the online validator". These kinds of comments indicate to me that the Structures specification may not yet be mature enough to given to the development community.

The Primer and Datatypes specifications are significantly more readable. Only one respondent felt that the Primer seriously needed to be written, and only two felt that the Datatypes specification seriously needed to be rewritten. Most felt that the Primer was either well written and helpful (8) or does the job (9), and a further 8 felt it was usable with some shortcomings. A few less than half (12) felt that the datatypes specification was usable with shortcomings, and another third felt that it was either well written and helpful (3) or at least does the job (6).

Complexity

The vast majority felt that it Schema is complex; half of these (14) feel that the features it offers justify this complexity, and half (14) do not. One respondent felt that it is not complex, and one respondent felt it is not complex enough.

When asked what the Working Group should do, almost two thirds (18) chose an option that included simplifying the feature set. Some respondents also made comments indicating that Schema could be made simpler by improving the design.

Simplify the Design and Rewrite!

Only 3 respondents felt that we should ship Schema as soon as possible, without significant change. A further 4 felt that we should keep the current design, make the prose more readable, and ship as soon as possible. More than two thirds (24) felt we should work on the design, saying either that we should keep the current feature set, and take one more shot to improve both the design of schema and the prose (6), or simplify the feature set, take one more shot to improve both the design of schema and the prose (18).

In fact, with 18 votes, this last choice by itself received support from almost two thirds of respondents. Clearly, respondents felt it was important both to simplify the design and to improve the prose.

When asked how long they were willing to wait, almost half (13) said they would be willing to wait 6 months. 7 respondents chose the option "shoot the engineer and ship it now!", but 6 respondents chose either 12 months (5), 18 months (1), or 24 months (1). Not only was 6 months the most frequent choice, it is probably the best compromise to satisfy the group of people choosing longer or shorter periods.

When asked what a redesign should involve, respondents offered a variety of suggestions, suggesting that we concentrate on modularity, simplicity, readability, reusability, extensibility frameworks, removing features, creating a minimal subset, or "dropping what is not well defined".

Conclusions

Respondents clearly felt that schema is important, and they also felt it is important to do it right. The mandate of this survey is fairly clear: simplify the design, rewrite the specs, especially the structures spec, and produce something simpler and cleaner in the next 6 months. It is also clear that there is a significant level of frustration with the Structures specification, and that this would be a good area for us to concentrate our efforts.

This mandate provides broad goals that we might choose to adopt, and gives an indication of the time frame in which we can work, but is not specific about the steps we should take to achieve these goals.

Actually, I believe it is the job of the Working Group to determine if there is a way to do so. I agree with the vast majority of respondents who feel that Schema is extremely important. Since Schema will form the basis of many vital technologies in the near future, I also think it is important to make it as simple and well-defined as we can, while providing the features that the community is asking for.

Cumulated Data

This section contains the raw data from the surveys. A simple tally would not convey the complete picture - for instance, in many cases, a single individual would check responses that might seem to be contradictory, and add explanations to the text. Also, I found that there were frequently combinations of questions that a single individual would respond to in unexpected ways - for instance, many individuals said they liked Schema and thought it should be released in its current form, but also said that the Schema WG should spend 6 months simplifying the design and improving the prose. Simply counting the checks would not be a useful characterization of what these individuals were trying to convey.

I wanted to let people see the patterns of an individual's response without identifying the individuals. To make this possible, I gave each respondent a single character, which was one of the following:

1234567890abcdefghijklmnopqrstu

In the rest of this message, I present the questions as they appeared on the survey. A tally of responses is shown, along with comments from individual respondants.

This raw data includes almost every bit of text found on the various emails I received, and did not select among the comments. I felt that fair reporting was more important than brevity, and did not want to influence the results by my choices.

How would you describe yourself?

Programmer 17 245680bcfginpqrtu
Software Architect 22 1245689abcdefghinorstu
Consultant 13 348cefglnopru
XML content developer 10 34568cgnor
Web developer 10 34578cgnrt
Database developer 7 236cgir
Other (please describe) 6 3gjkmq

Respondent 3: Author

Respondent f: boat rocker and XML advocate in www.ie.com - currently involved in legacy financial system and content management integration!

Respondent g: other: schema WG member (Editor's Note: other information omitted because it uniquely identified the respondent).

Respondent j: researcher

Respondent k: Researcher (closest to software arch. here)

Respondent m: Engineering manager for a software development department. I am more concerned with project and technology planning, and do not spend much time on particular projects. We develop mostly network management systems (100 people, 15 or so projects at any given time, growing rapidly).

Respondent q: data standards architect

What have you done with Schema?

I have read the working drafts. 29 1234567890abcdeghijlmnopqrstu
I have written schemas based on the Working Drafts. 18 2346789bcdgklmrstu
I have written schemas in other schema languages such as SOX, RELAX, or XML Data Reduced. 13 2369cfjlnqrtu
I am writing software based on schemas 11 249fghioptu

I have read the working drafts.

Respondent 0: mostly just the primer

Respondent f: I have *attempted* to read the WDs - I have retreated to experimenting against the online validator

Respondent g: well...one of them front-to-back, all of them in part.

I have written schemas based on the Working Drafts.

Roughly how many schemas have you written?
2 4 7klm
3 1 3
3-4 1 4
4 1 b
5 1 f
10-12 1 9
10-15 1 g
around 15 1 u
20 1 6
3 dozen 1 8

I have written schemas in other schema languages such as SOX, RELAX, or XML Data Reduced.

Respondent f: DCD, used as human readable specs, for cross-company cross-language integration

I am writing software based on schemas

Respondent 3: I am writing documentation based on schema, not software.

Respondent 4: I have started working on a general purpose Schema validator module. It is far from complete though, and I don't have as much time as I'd like to work on it.

Respondent 5: I have written special purpose mini-languages accomplishing some schema type purposes for driving XML transformation applications (non-XSLT). I read through the drafts fairly quickly, found an error in the primer (section 5 Adv Concepts III, xml uses element 'zip' but schema defines regiontype as containing element 'zipcode'. Schema uses 'zip' elsewhere). Parts 1 and 2 are rather verbose, could probably cut the length by 50% and increase clarity.

Respondent 9: Training and self-education, parsing data for CommerceOne (SOX), BizTalk (XML Data Reduced)

Respondent g: I'm hacking a DTD->schema perl script ... I'm also collaborating on (a schema validator) mostly on the web front-end.

Respondent i: I generate relational database schemas from DDML schemas. Note that because DDML essentially matches DTDs, what I really do is generate relational schemas from DTDs -- the DDML schemas are first translated to internal DTD objects. Note that the DDML processing software was not as easy to write as I thought it would be, due to a design flaw in the way DDML handles namespaces. (We allowed namespaces to be defined at virtually any level of the schema, which meant that you have to keep a stack with the current definitions. Not really hard but, in retrospect, needlessly complex. Better to define the namespaces once at the top of the schema and get it over with, assuming you can still handle combining definitions from multiple schemas.) So, although I don't need/use them now, simple features like data types and advanced features like inheritance will be interesting to me in the future.

Respondent m: 2 related schems, one encoding the CIM metaschema, the other encoding a specific CIM information model. (Common Information Model of DMTF)

Respondent p: I am involved as editor in writing the spec for ISO TC184/SC4 (STEP) to represent product data in XML. We will move to Schemas as soon as it is stable and good!

Respondent t: Editors note: description of two interesting systems, but the description is specific enough to identify the respondent, so I am omitting it in the report pending approval from the respondent.

Have you used XML parsers that support Schema?

No 9 150ijmnqu
Xerces 6 2389rs
Oracle 1 6
XSV 4 68fg
XmlSpy 5 67cdl
IBM for C++ V2.3.1 1 h
xml4j early release 1 k
Extensibility 1 l
MSParser 1 o

Respondent 4: Apart from the tiny subset of my own I haven't used any. The main use I've had for my schemas has been to communicate them to others in my organisation who understand them.

Respondent b: We have our own schema engine, but it is not part of the parser.

Respondent e: Not yet. Except looked at MS examples with XDR.

Respondent f: No, just the online validator. Editors note: based on this, I added f to the box for XSV.

Respondent p: Used XML Authority to generate schemas (but it could not read in the XML Schemas in XML Schema, mainly due to problems with the XML Schemas spec!)

Respondent q: no - i do my designing in dtds all the way, then convert to schemas and add on what is necessary - worked some with validators though.

Do you plan to use Schema?

I, or my company, will write software based on Schema. 16 23489befghinpqtu
I, or my company, will depend on software based on Schema. 17 23689bdefghnqrstu
I, or my company, will need to write Schemas. 20 2346789bdefgklnoqrtu
We will probably use schemas, but are not dependent on them. 8 1340kmop
DTDs are adequate for my needs. 4 350o
I do not know at this time. 2 5a

Respondent 3: Seems like a contradiction, but that's consulting!

Respondent j: This is probably not a good question, since employees of large companies have to mark the first three.

Respondent m: I am interested in XML Schema for research collaboration with universities, and internal investigations that may impact future projects. If it were just my company answering, DTDs are probably adequate for what we can foresee.

Which of the following best captures your feelings about the current state of Schema?

We like it, and would like to see it become a recommendation in its current form. 8 46890fhq
We like it, but we think it needs some changes. 11 27dgimnrstu
We need something like Schema, but it needs serious work. 11 135abjklnop
We do not need anything beyond DTDs. 1 o

Respondent e: We need a standard schema language to match the object oriented languages (C++, Java, etc.) and database systems which we need to interface with. Sending the schemas back to the working group does not mean the next revision is going to be better. It will also fragment the schema space and people will have to choose XDR, SOX, RELAX, etc.

Respondent g: I think it's very much ready for Candidate Rec, i.e. a massive "please try it out and see what you think" phase. I wish the spec weren't so hard to read, but I think that with the primer and various tools -- and maybe some more stuff like UML diagrams -- it's acceptable.

Respondent i: Specifically, define implementation levels. "DTD", "DTD plus simple data types", and "the whole shebang" might be enough.

Respondent m: A major problem is readability of Part I: Structures. I think this can be addressed by adding a large "reference guide" to the Primer that is comprehensively discusses the XML representations in Sec. 4 for schema authors, with only minimal reference to the Abstract Data Model and lots of use cases and motivation. This should provide a good introduction to the reading the abstract data model later.

In general, do you think Schema is feature-rich enough?

Schema supports all the features I really need, but I would prefer more. 5 78emr
Yes, Schema supports all the features I would like. 10 269adfgiqs
Schema supports features that I am unlikely to use. 16 13450bcfjlnoprtu

Respondent 4: But then looking at the spec I get the impression that it has the same problem as other big specs. Everybody will use only a subset, but no two parties will use the *same* subset.

Respondent g: I would have preferred to do a v1.0 Recommendation with less stuff, but that's sunk cost now -- it's not cost-effective to remove it.

Respondent k: => I think all features are worthwile (there is some I would like to see added, e.g. extensible datatype -- I mean really extensible -- and some I will never use -- e.g. keys). But trying to put all there at once is too big a challenge, especially with all those guys coming from different horizons and wanting their features to be there). So, I think that Schema is not modular enough.

Respondent l: Datatyping is the most needed feature of Schema Respondent m: There some things I don't know how to do because I haven't really studied them yet, like handle case insensitive strings. I don't really have too many specific ideas about added features, I think adding them in a later release is better, the priority should be to get it out with as simple a feature set as possible, as long as future innovation is not blocked.

Respondent t: Schema supports some features (partically complex type extension by restriction) that I think are minimally useful and maximally complicated or poorly defined. Plus it is missing some extremely useful and simple to implement features such as conjuction types (LC-2, I think) and open enumerations, so I'm in the awkward position of thinking that it is too fat in some places and too lean in others.

Is the design of Schema too complex?

Schema is not complex. 1 2
Schema is complex, but the features it offers justify this complexity. 14 46890acdefgmqs
Schema is much too complex, even for the features it offers. 14 135bhjklnoprtu

Respondent 7: Schema is not complex enough! It does not allow you to do things like validate measurements.

Respondent g: I don't feel very confident about this answer. I would much prefer to really study the theory and the alternatives in detail and say with confidence "the functionality the community is after cannot be achived with substantially less complexity" but I haven't managed to find enough hours in the day. On the other hand, the design we have is fairly mature, and getting moreso all the time. In a perfect world, it might be simpler. But from here, we can't get substantially more simplicity without delaying by months, if not years. I hope our spec isn't another Ada... though that's not a huge crime: Ada doesn't stop the bulk of the community from getting its job done. I *really* hope our spec isn't another C++, i.e. a crime that will hinder the work of the bulk of the innocent engineers out there because it's complex and poorly specified. I don't think our spec is a lean as, say, Modula-3 or even Java (though if you add the java class libraries, our spec starts to look pretty lean and mean ;-), but I think it compares well with XML 1.0: XML 1.0 isn't all that pretty, but it gets the job done. XML 1.0 has a certain amount of stuff that everybody needs, but it also has a bunch of stuff that only some folks need; and the spec is hard to read, for what should be a simple language spec. But the tools work and the community benefits greatly from it.

Respondent k: add modularity, and I would change my answer to the second answer. Respondent l: The wording in the schema specification is unreadable and not understandable to mere mortals.

Respondent m: Some of the nice features are not so clearly motivated in the documents -- like equivalence classes and polymorphic references. Better non-normative documents can address that. Incidentally, should they really be called equivalence classes when there is no clear symmetric relation between the declared element and the element of its assigned equivalence-relation cell? Maybe "assigned equivalence cell" or something is better, and identify some kind of partition under the validation process. (This issue was mentioned by Benjamin Pierce in his article on Regular Expression types).

Respondent t: I think that there are several areas that could be greatly simplified, again specifically complex type extension by restriction is a flagrant example. In many cases, the schema for schema could have been designed to constrain allowable cases, but that was placed into the prose of the spec.

How important is it to release Schema quickly?

It is vital to ship Schema quickly, even if there are flaws. 12 6789defginqu
It is vital to make sure Schema is good, even if it takes longer. 17 123450abchjmoprst

Respondent g: by "ship" I mean CR. Respondent i: This assumes that the flaws are things where you can say, in retrospect, that there was a better way, not things that prove to be impossible to implement.

Respondent k: it depends how flawed it is and how long it takes.

Respondent l: Give us the minimal functionality of schema while working on eliminating the flaws.

Respondent m: I think most of the shortcomings should be addressed in future releases. However, I am open to reducing the feature set for 1.0, and moving some of the already designed features into 2.0 after more work.

Which of the following features do you anticipate using?

XML notation for schemas. 26 1234567890bcdefgijklmnorst
Data types. 28 123467890abcdefgijklmnoqrstu
Schema composition. 18 23689abcdefijkmnsu
Identity constraints. 17 2346890bcefimnors
Refinement. 13 24689bcfgikms
Element equivalence classes. 14 36789bcgimnoqs
Attribute-group definitions. 20 3456789bcgijlmnoqstu
Nulls and nullability. 12 34689abceims
Use of schemaLoc to associate schema with document. 18 1234689bcdegimnqsu

Respondent g: Aside from identity constraints, I've already used all of the ones I X'd. Identity constraints are used in the schema-for-schemas, and I'm a collaborator on that, so in a way I've used it.

Respondent m: But I could live with it if the last four were postponed to 2.0. Then I would have something to look forward to. :) Alternatively, they could be put in a non-binding part of the spec.

Respondent p: As others have stated, I think that release 1 should be data structures plus DTD in XML syntax.

Respondent t: probably will avoid Refinement and recommend others avoid in its current state. Probably will use named groups in preference to Element equivalence classes. Will not use SchemaLoc as primary association means.

Which of the following features seem to be unnecessary?

XML notation for schemas. 1 q
Data types. 0 ----
Schema composition. 2 3o
Identity constraints. 6 359gju
Refinement. 8 19jlnotu
Element equivalence classes. 6 1bjltu
Attribute-group definitions. 2 12
Nulls and nullability. 8 3bgjnoqu
Use of schemaLoc to associate schema with document. 4 bjlo

Identity constraints.

Respondent 3: too many

Respondent g: I think it could be layered on top or added later.

Refinement

Respondent 3: useful, though I'm uncertain about current form.

Nulls and nullability

Respondent 3: for some tasks

Respondent g: I don't grok nulls.

General comments

Respondent l: Until we get a working schema language, I don't feel comfortable identifying what we need in 2.0. We need experience.

Respondent m: I haven't studied schemaLoc, the others seem worthwhile. I've actually used the first five and attribute-group definitions, they don't seem broken. Nulls may be postponable, especially if Query WG has not developed a strategy.

Respondent s: "Unnecessary" is a strong word. "Not useful" might have been better, but I still wouldn't have checked any. They'll all be useful.

Respondent t: I believe use of attribute groups and particle groups can more simply and effectively accomplish the objectives of refinement, however I am resigned to refinement being in the spec. Named particle groups can accomplish the same objectives as element equivelance classes.

Which of the following features should be removed from the 1.0 specification, and added to release 2.0 after the development community has had time to experiment with the concepts?

XML notation for schemas. 1 q
Data types. 1 5
Schema composition. 6 135jor
Identity constraints. 8 135bijoq
Refinement. 10 139ijnoqrs
Element equivalence classes. 13 136bfijmnorst
Attribute-group definitions. 4 1bir
Nulls and nullability. 10 13bijmnoqr
Use of schemaLoc to associate schema with document. 6 bfjmor

Refinement

Respondent t: particularly complex type restriction.

General Comments

Respondent g: If I could have the time it took to develop them back, I might remove them. But the time has been spent; it's not useful to remove the features now.

Respondent m: I'd really hate to lose Refinement. Identity constraints are attractive, but I could live with postponement if a significant sector thinks they are broken. I'd be happy if all of those I marked were left in, but I wouldn't complain loudly if they were postponed. I don't really understand the issues behind the three I marked, I can't say if they are broken.

Respondent s: If it can be demonstrated that it will speed up the progress of 1.0

Are there important features that Schema is missing, and must have for a 1.0 release? If so, please list them.

Respondent a: The fact that an ID cannot be look like a pure number, e.g. a Social Security number, is a major limitation. I understand that this comes from XML itself, rather than from Schema.

Respondent d: I would like to see an XML syntax used instead of PERL regular expressions. It seems strange to use XML for everything except that part of the data typing.

Respondent e: Better documentation and explanation of the current feature set.

Respondent g: clear specification of the value space for dates and for ID/IDREF. Respondent l: Readablity of the specification. A valid DTD to support schema development.

Respondent m: I haven't studied the issue in detail yet, but I am interested in open content. Perhaps a mechanism to still use model groups for inserting elements, but allow an 'open' attribute that will affect things like equivalence classes. Unfortunately this might make things more complex, so it may be better to postpone the whole thing.

Respondent o: De-coupling of data definitions from schema specification Better model representation techniques to replace minOccurs/maxOccurs Simpler syntax thru use of business representational methods such as Bizcodes

Respondent p: Yes. For data it is essential to be able to indicate where data is not ordered, i.e. the element instances can appear in any order. I did not see this info in schema. Respondent r: Entity definitions Respondent t: Open enumerations (basically a non-exhaustive list of anticipated values), conjunction types.

Readability of Specifications

Respondent k: I have not read them since february (when I noted that I had changed again). The main issues to my opinion are:

These comments are also true of some other spec (e.g. MathML). And I think that, overall, the Schema documents are better than RDF's.

Readability of Schema Part 0: Primer

Overview: were you able to get the big picture?

Yes 17 12346890bcfghmnsu
--- 4 5ejq
--- 4 7dlr
--- 2 op
No 1 a

Ease of Reference: were you able to find information when you needed to look something up?

Yes 2 69
---- 8 34efhqsu
---- 9 258cgjlmr
---- 4 7bdo
No 2 1a

Level of Detail: were the important details spelled out?

Yes 2 4u
---- 11 23569bdefqs
---- 6 1cghmr
---- 4 78lo
No 1 j

Readability: compared to other technical specifications, was it understandable?

Yes 7 4890gmu
---- 10 2356befhqs
---- 4 1jor
---- 2 cl
No 2 ad

Respondent l: This question depends on the spec. If you compare it to Schema 1, then it is very readable. If you compare it to XML 1.0 it misses the mark.

Overall, which of the following statements do you most agree with
This is well written and helpful. 8 3680gmsu
It may not win the Pulitzer Prize, but it does the job. 9 245behnoq
There are shortcomings, but it is usable. 8 179fjlpr
I found it hard to understand some key concepts. 2 ad
Readability seriously interferes with the purpose of this document. This really needs to be rewritten before it is released. 1 c

Respondent s: I had already struggled through most earlier drafts of parts 1 and 2 of earlier drafts, so part 0 came pretty easy to me.

Respondent t: I can't really comment since I never started long before the Primer was written.

Readability of Schema Part 1: Structures

Overview: were you able to get the big picture?

Yes 3 69c
---- 6 4hostu
---- 5 25egn
---- 5 dfmqr
No 9 1378abjlp

Respondent m: I was able to struggle through only because of the time I have invested in studying earlier drafts. I worry about how somebody relatively new to Schemas and XML would cope. I find that I can't give it to any of my colleagues to read, even if I think Schemas should be on their radar. The Primer is nice, but not comprehensive enough for a lot of the material in Structures.

Ease of Reference: were you able to find information when you needed to look something up?

Yes 0 ----
---- 7 269egst
---- 7 3457cho
---- 7 bdmnqru
No 7 18abfjl

Respondent m: paper version. Related information is spread out in too many places, I don't think I would have been better off following hyperlinks. I do most of my technical reading on the screen, but sometimes you just have to stare at thing side by side. Pictures would help a lot, including UML diagrams (Rational ROSE has a tool that converts at DTD to a class diagram, including special icons (stereotyped classes) for model groups.)

Level of Detail: were the important details spelled out?

Yes 4 26gs
---- 5 3bcmu
---- 10 4589dehnoq
---- 2 fr
No 3 17l

Respondent b: I don't really know. It's hard for me to find them.

Respondent j: Don't know, since I cannot read Part 1.

Respondent m: A lot of detail is there, but sometimes there seems to be a framework guiding the spec but it is mysterious to me. Perhaps it is a reflection of the theoretical immaturity of this area of work, but it would be nice to have more answers to "why", and not just what and how. That material may not belong in the spec, but informational Notes would be nice.

Readability: compared to other technical specifications, was it understandable?

Yes 0 ----
---- 5 6bgho
---- 3 459
---- 9 2dfmnqstu
No 9 1378bcjlr

Respondent m: I compare it to the TEI specs, so I know MSM can do a lot better. Perhaps it needs more time.

Overall, which of the following statements do you most agree with
This is well written and helpful. 0 ----
It may not win the Pulitzer Prize, but it does the job. 5 6bgou
There are shortcomings, but it is usable. 5 459hs
I found it hard to understand some key concepts. 6 2defnq
Readability seriously interferes with the purpose of this document. This really needs to be rewritten before it is released. 15 1378abcfjlmprt

Respondent 2: Although this document was extemely difficult to digest, after re-reading it about 5 times I finally feel that I have a good handle on how things work. However, I still tend to refer to the XML syntax reference (chpt 4) rather than the framework (chpt 2 & 3) in order to look something up. In general, Chapters 2 and 3 are where a lot of readablity work is needed. I don't mind complex documents, but the language obscures the meaning in these sections. Part of the problem is that there are no concrete examples to help ground the reader (even though the XML syntax comes later in the spec (chpt 4), its not useful back there, something concrete is needed here) -- I think it would be best to lay out the syntax independent framework but still use examples from a concrete reference syntax, and then have chapter 4 as a reference. It would be clearer. Finally, in Chapter 4 it is sometimes very difficult to find the definitions and references for terms. For example, the schema element information item in section 4.1 lists a "blockdefault" attribute, and it is exceedingly difficult to track down just what this is and why it would be used. There could be links from each attribute name to a precise definition of its use in all of the diagrams. The links that are provided (in the next table, for example to "type_definitions" and that links to section 3.1) that refer to sections 2 and 3 are too abstract to be much use until you understand the spec thoroughly. In summary, although the spec should be comprehensive and syntax independent, a typical XML developer that wants to represent DTD syntax in XML and use datatypes should be able to scan the spec and understand basically how to do so in an hour or so. As it stands, it takes several readings to understand this document reasonably. Not that I could do any better -- I fully appreciate the difficulty of the task and appreciate the effort that everyone has put into writing the current drafts.

Respondent f: OTOH I could live with it being the reference doc if there was a authorative user guide (not intro) which followed the golden rule: - explain the problem - illustrate the problem - explain the solution - illustrate how the solution solves the problem

Respondent s: It just needs a lot of attention to what I call "Strunk and White" issues.

Respondent t: The complexity of the document is an indication that certain things aren't well designed. Removal of certain features and refinement of schema for schemas could remove a whole lot of the complexity.

Readability of Schema Part 2: Datatypes

Overview: were you able to get the big picture?

Yes 10 2467bcgnou
---- 11 359defjmqst
---- 4 18lr
---- 0 ----
No 1 a

Ease of Reference: were you able to find information when you needed to look something up?

Yes 5 267gu
---- 12 3bdefjlmnqst
---- 7 14589cr
---- 0 ---
No 1 a

Level of Detail: were the important details spelled out?

Yes 4 267o
---- 13 45bcdeflmnqsu
---- 6 138jrt
---- 2 9g
No 1 a

Readability: compared to other technical specifications, was it understandable?

Yes 3 67u
---- 10 24egjmoqst
---- 9 13589bdfn
---- 3 clr
No 1 a

Overall, which of the following statements do you most agree with
This is well written and helpful. 3 26u
It may not win the Pulitzer Prize, but it does the job. 6 4bdfst
There are shortcomings, but it is usable. 12 135789ejlmoq
I found it hard to understand some key concepts. 2 gr
Readability seriously interferes with the purpose of this document. This really needs to be rewritten before it is released. 2 ac

Respondent 4: Actually, for 1 and 2, it all depends if they are to be read by schema writers or by implementors. I know it isn't the W3C's job to provide implementation details, but both groups often need different views of the same spec, and mixing both in the same document often results in confusing information (in that depending on what you want from it, you have to filter out parts).

Respondent g: dates

Respondent l: This one is too long for what it does.

What do you think the Schema WG should do?

Ship as soon as possible, without significant change. 3 68g
Ship as soon as possible, making the prose more readable, but without changing the design of schema itself. 4 29eq
Keep the current feature set, take one more shot to improve both the design of schema and the prose. 6 7dfmns
Simplify the feature set, take one more shot to improve both the design of schema and the prose. 18 1345abchijklnoprtu

Respondent g: to CR.

Respondent m: I am also open to simplifying the feature set.

If the Working Group were to spend time redesigning Schema, what do you think we should spend our time doing?

Respondent 1: Emulating Relax

Respondent 3: Develop a core set of features on which the more advanced features can later be layered smoothly. Leaping into inheritance and datatype facets seems like a bad idea for a 1.0 specification. We need something quickly, but not all this.

Respondent 4: Without a doubt, making it as modular as can be. Monolithic specs are hard to learn, hard to implement and extremely painful to update (without breaking another part). Cutting it down to small, manageable pieces will imho make everyone's jbo easier.

Respondent 5: I think a re-examination of the goals of XML Schema are in order. The shear size of the spec in comparison to XML 1.0 should have given a hint that a bit much was being defined. DTDs may be inelegant (I wrote a validating parser so I'm no big fan), but just addressing the major shortcomings would have resulted in a far simpler specification. The purpose of Schemas should be re-examined. The current design, allowing deep but not ultimate specification of element patterns and datatype definitions, begs one question: what is going to use it? A Schema is not much use to an application producing an XML document describing a purchase order from a database (does it generate by trial and error and then see if the result is valid according to the Schema?). Such an application will have its own logic to produce the document structure. If a document is produced by such an application, it should be valid. A receiving application needs its own logic to interpret the document structure and content. All a producing and consuming application need to know is a URI for the document indicating a guarantee that the arbitrarily complex specification of content is met (for instance this is an IRS 1999 1040 form) they do not need an expression of the specification - each has code to produce or interpret it. The problem is such an expression is a third representation that must be kept in sync with the other two and can't be used to automatically create them. It seems to me human interaction is the main purpose - form entry or XML editors. It may cover 90% of validity concerns for such purposes, but there are always holes - valid zip codes, check digit calculations, etc. There are also cross element/attribute constraints - does that area code match at the state. I could add filtering/transforming application that convert from one document form to another, but I haven't seen that presented as a reason for Schemas. Most of what's in Schemas makes sense, but that's not the point. It seems mis-aimed. I would limit it to mostly an XML representation of DTDs and reducing the overuse of parameter entities for re-use of attributes and element patterns.

Respondent 7: Look at reusability issues a bit more. (These may be OK, but they are just not explained. Things like reusing part or all of an enumeration, restricting a simpleType definition to a subset thereof, restricting and extending complexTypes without having to completely redefine them, etc.) In general look at the relationships between different schemas in a bit more depth.

Respondent 8: Simplifying it

Respondent 9: Make the specs more readable.

Respondent a:

  1. Get the underlying semantic model (aka InfoSet) correct.
  2. Make sure that datatypes are well supported.
  3. Make sure that there is an easy way for consumers to ignore elements and attributes they do not want to process. This resembles the functionality provided by "architectural forms" but the implementation may be quite different.
  4. Make sure it is well coordinated with XML Query. (I know, this makes the problem harder because there are now two moving targets.)

Respondent b: Throwing things out for the 1.0 release, and rewriting to make things clearer.

Respondent c: Create a legal simplified subset.

Respondent d:

  1. Make it completely XML (get rid of regular expressions).
  2. Make it much clearer how namespaces work (rewrite the section on namespaces)
  3. Create a common sample for all three documents and stick to it for all examples
  4. Work with other groups to create XML Schema schemas for their mark up to verify the features
  5. Make sure that a simple schema is simple to write
  6. Provide support for variables (so that I can specify the value at parse time)

Respondent e: Follow the Microsoft model please, ship 1.0 and listen for the feedback and work to make 2.0 much better. As I understand it, the work is in defining the data in the Schema file. Once you have it, you can transform it into another schema format.

Respondent f: Knock up some knock-out use-cases and validate the feature set and documentation against them

Respondent h: Make it simpler.

Respondent i: Implementation levels.

Respondent j: Begin with DTD + datatypes in the XML syntax. Then, remove doubtful features as much as possible (e.g., entities and notations).

Respondent k: Carefully droping things that are not in a clearly definitive state taking care that they could be added later on.

Respondent l: Create a simplified Schema set that provides the current functionality of DTD's with datatyping. Write a specification that is clear and unambiguous. Get this schema specification out the door ASAP, then work on the more complex and obscure feature sets of schema.

Respondent m: Provide a separate Note about use cases, and make sure the spec is well motivated to the typical "schema author" reader. There can be separate chapters targetted at implementors. Decide on postponing features, while ensuring a smooth roadmap to the future.

Respondent n:

  1. Extensibility Framework.
  2. Notations and non-standard datatypes.
  3. Co-occurrence constraints.
  4. Evolvability.

Respondent o:

  1. Look long and hard at GUIDES, eDTD, Bizcodes and work with the ebXML WG to develop sensible simple business based mechanisms that can be handwritten and understood without the need for complex tools.
  2. De-couple the data context definitions from the data modelling syntax so that Schema can focus purely on describing the data structure.
  3. Stop trying to build SGML V2.0
  4. Seriously question the premise that pointy-bracket structures are really an ideal modelling metaphor - rather than just a data wrapper?
  5. DTD's use nested parenthesis, clearly the limitation is ASCII chars. Once this understanding is reached then we can not over design a solution - but instead make V1.1 simple and complete.

Respondent p: The DTD for XML Schema is, IMHO, pretty poor because it fails to enforce many of the 'rules' which could easily be incorporated into the DTD, e.g. 'if you have this attribute then you should not have this and this one' - that's easy to enforce in a DTD! Your time would be best spent using an existing formal definition language such as UML or (better) EXPRESS. That would force you into a clearer more formal definition and reduce the size of your document considerably. You probably do not know how to do this, then you need to get some help from a data modeller! XML Schemas is a spec crying out for a formal model, to my mind. You are trying to tackle a problem that is too complex to solve using English statements and you will fail if you do not leverage from these existing techniques.

Respondent t: Unifying the complex and simple type hierarchy, making schema for schema more effective in validating schema by using more structural features (such as an explicit <restriction> element that contains restriction only forms of element, attribute, etc).

If you feel the Working Group should continue working on Schema, how long would you be willing to wait for an improved version of XML Schema?

Shoot the engineer and ship it now! 7 689egin
6 months 13 24bcdfhimpstu
12 months 5 135ao
18 months 1 3
24 months 1 r

Respondent 7: 3 months I can wait; 6 months is too long.

Respondent b: Throwing things out and cleaning up what's left shouldn't take that long.

Respondent j: Frankly, I do not feel that it should continue. It should be cancelled.

Respondent k: This completely depends on software availability. I think that everyone has been happy to wait for XSLT because XT was available (and corresponding to what was on the paper). At the time I looked at Schema, this was not the case and at the cadence the Schema group adds new features, I would bet they did not implemented them at the same time.

Respondent l: The e-commerce world needs it now but I am afraid that in its current state it will cause more problems than it is attempting to fix. If I were to make a recommendation, I would recommend that a simplified version be ready in less than 3 months. The industry has been waiting a very long time for schema. Industry standards groups are currently writing DTDs that will support schema's and plan to migrate to schema as soon as there is a working schema specification.

Respondent m: I think the gap between the April 7 draft and my concept of an ideal CR for Part 1: Structures is too big to be closed without another WD. I would be happy if it went into CR by January or February, but December or November would be nicer. Postponing some of the controversial features may be needed to meet this target.

General Comments (not assigned to any question)

The poll was taken via email, and the responses often included comments that were not assigned to any particular question. These comments are listed here.

Respondent 2: Hope this is useful to you. I had some difficulty in deciding for several of the questions about whether it was too complex, and decided that I think it is mostly how Structures-1 is written, rather than XML Schema itself. We'd like to see a Rec as soon as possible (we are waiting), but it would be better if it was stable and had broad support, and all controversial issues ironed out. The controversy surounding the Namespace Rec shows exactly why some caution is in order. Thanks for all of your effort!

Respondent 3: Thanks for doing this! My experience with Schemas has been primarily in the line of writing tutorials, not code, so you may want to take that into account.

Respondent 6: IMHO, its been MUCH too long already!! Ship it. There can always be a version 2, if need be. And you may end up *adding* some features... ;-)

Respondent 0: I think Schema will be useful, but I think there is room for both it and a lightweight schema system that does little more than DTDs but uses XML notation and supports namespaces. Starting such an initiative would appease the "Schema is too big" people.

Respondent a: I have been doing software development for almost thirty years, mostly in the area of database management systems, but also information retrieval. XML lies at the intersection of these fields and I have followed it pretty actively for about two years now. I've read all the XML specifications, and most of the drafts, plus lots of technical reports, XML-DEV etc. I am afraid that I must agree with the many other people who have said that the spec is nearly impossible to understand, simply being reading it. I did not have the time to do the word by word parsing required. At a minimum it must be totally rewritten, even part 0.

Respondent b: Hey, thanks for doing this Jonathan. Just last night I was debating whether or not to write up a very long document on all the things I found very confusing and misleading within Part I of the spec. I'm answering this assuming that my votes remains anonymous.

Respondent m: And a big thank you to every body who has been slaving over this work. I think you folks are shifting the foundations of computing and communications. There is an "information sharing" revolution taking place that is at least as important as the shift from structured programming to objects. Schemas are a key piece in the puzzle, and a good spec will making it happen sooner; I just hope it will be accessible to people who should do before they are done to. For better or worse, my grandkids will live differently because of this spec.

Respondent s: Hello Jonathan! More data for you. Some general comments: the big step from the original attempts at providing "inheritance" features to the current extend-via-appending or restrict choice with a "maybe we'll expand on this later" caveat could serve as a model for addressing many other issues: simplify them, even at the cost of restricting some power, while still leaving them in, with the option of extending them later. One category of features that Liora didn't address as a category in her article is what I'd call "database round tripping" features. I think a lot of people consider these as a higher priority than anything but data typing (e-commerce and all that) and I imagine they're not really difficult to describe and implement. The difficult stuff has to do with features that allow more modular, OO-like schema design features, and while great and important I think they are good candidates for further simplification and postponement (but not cancellation). Attribute groups (and named model groups, or whatever they're called) should be left in just like including, because we need that backward compatibility with general entities. And thanks for all your work on this!

The Original Questionnaire

This appendix contains the text of the original Questionnaire.

A recent article on XML.com (http://www.xml.com/pub/2000/07/05/specs/lastword.html) 
raises concerns about the W3C XML Schema specification. As a member of the Schema WG, I'm still deciding 
how to vote on moving Schema to CR. I would be interested in hearing whether the members of this mailing 
list agree with the conclusions in Liora's article. I am not doing this in any official capacity, I am 
doing this because I want to know.

I'm mainly interested in the opinions of people who have actually done something with Schema. Please send 
your responses to me - I will tally the results and post them to this mailing list, and will also report 
them to the Schema Working Group.

For each of these questions, check as many boxes as apply, and feel free to add comments.

0. How would you describe yourself?

[  ]  Programmer
[  ]  Software Architect
[  ]  Consultant
[  ]  XML content developer
[  ]  Web developer
[  ]  Database developer
[  ]  Other (please describe)

1. What have you done with Schema?

[  ]  I have read the working drafts.
[  ]  I have written schemas based on the Working Drafts.
      (Roughly how many schemas have you written?)
[  ]  I have written schemas in other schema languages such 
      as SOX, RELAX, or XML Data Reduced.
[  ]  I am writing software based on schemas
      (Please describe this software, unless it is confidential.)

2. Have you used XML parsers that support Schema? If so, which ones?

3. Do you plan to use Schema?

[  ]  I, or my company, will write software based on Schema.
[  ]  I, or my company, will depend on software based on Schema.
[  ]  I, or my company, will need to write Schemas.
[  ]  We will probably use schemas, but are not dependent on them.
[  ]  DTDs are adequate for my needs.
[  ]  I do not know at this time.

4. Which of the following best captures your feelings about the current state of Schema:

[  ]  We like it, and would like to see it become a recommendation in its current form.
[  ]  We like it, but we think it needs some changes.
[  ]  We need something like Schema, but it needs serious work.
[  ]  We do not need anything beyond DTDâ?™s.

5. In general, do you think Schema is feature-rich enough?

[  ]  Schema supports all the features I really need, but I would prefer more.
[  ]  Yes, Schema supports all the features I would like.
[  ]  Schema supports features that I am unlikely to use.

6. Is the design of Schema too complex?

[  ]  Schema is not complex.
[  ]  Schema is complex, but the features it offers justify this complexity.
[  ]  Schema is much too complex, even for the features it offers.

7.  How important is it to release Schema quickly?

[  ]  It is vital to ship Schema quickly, even if there are flaws.
[  ]  It is vital to make sure Schema is good, even if it takes longer.

8. Feature set

8.a. Which of the following features do you anticipate using?

[  ] XML notation for schemas.
[  ] Data types.
[  ] Schema composition.
[  ] Identity constraints.
[  ] Refinement.
[  ] Element equivalence classes.
[  ] Attribute-group definitions.
[  ] Nulls and nullability.
[  ] Use of schemaLoc to associate schema with document.

8.b. Which of the following features seem to be unnecessary?

[  ] XML notation for schemas.
[  ] Data types.
[  ] Schema composition.
[  ] Identity constraints.
[  ] Refinement.
[  ] Element equivalence classes.
[  ] Attribute-group definitions.
[  ] Nulls and nullability.
[  ] Use of schemaLoc to associate schema with document.

8.c. Which of the following features should be removed from the 1.0 specification, and added to release 2.0 
after the development community has had time to experiment with the concepts?

[  ] XML notation for schemas.
[  ] Data types.
[  ] Schema composition.
[  ] Identity constraints.
[  ] Refinement.
[  ] Element equivalence classes.
[  ] Attribute-group definitions.
[  ] Nulls and nullability.
[  ] Use of schemaLoc to associate schema with document.

8.d. Are there important features that Schema is missing, and must have for a 1.0 release? 
If so, please list them.

9. Readability of Specifications

9.a. Schema 0: Primer

Overview: were you able to get the big picture?
Yes [  ] 1      [  ] 2     [   ] 3    [   ] 4    [   ] 5 No

Ease of Reference: were you able to find information when you needed to look something up?
Yes [  ] 1      [  ] 2     [   ] 3    [   ] 4    [   ] 5 No

Level of Detail: were the important details spelled out?
Yes [  ] 1      [  ] 2     [   ] 3    [   ] 4    [   ] 5 No

Readability: compared to other technical specifications, was it understandable?
Yes [  ] 1      [  ] 2     [   ] 3    [   ] 4    [   ] 5 No

Overall, which of the following statements do you most agree with:

[  ]  This is well written and helpful.
[  ]  It may not win the Pulitzer Prize, but it does the job.
[  ]  There are shortcomings, but it is usable.
[  ]  I found it hard to understand some key concepts.
[  ]  Readability seriously interferes with the purpose of this 
      document. This really needs to be rewritten before it is released.


9.b. Schema 1: Structures

Overview: were you able to get the big picture?
Yes [  ] 1      [  ] 2     [   ] 3    [   ] 4    [   ] 5 No

Ease of Reference: were you able to find information when you needed to look something up?
Yes [  ] 1      [  ] 2     [   ] 3    [   ] 4    [   ] 5 No

Level of Detail: were the important details spelled out?
Yes [  ] 1      [  ] 2     [   ] 3    [   ] 4    [   ] 5 No

Readability: compared to other technical specifications, was it understandable?
Yes [  ] 1      [  ] 2     [   ] 3    [   ] 4    [   ] 5 No

[  ]  This is well written and helpful.
[  ]  It may not win the Pulitzer Prize, but it does the job.
[  ]  There are shortcomings, but it is usable.
[  ]  I found it hard to understand some key concepts.
[  ]  Readability seriously interferes with the purpose of this 
      document. This really needs to be rewritten before it is released.


9.c. Schema 2: Datatypes

Overview: were you able to get the big picture?
Yes [  ] 1      [  ] 2     [   ] 3    [   ] 4    [   ] 5 No

Ease of Reference: were you able to find information when you needed to look something up?
Yes [  ] 1      [  ] 2     [   ] 3    [   ] 4    [   ] 5 No

Level of Detail: were the important details spelled out?
Yes [  ] 1      [  ] 2     [   ] 3    [   ] 4    [   ] 5 No

Readability: compared to other technical specifications, was it understandable?
Yes [  ] 1      [  ] 2     [   ] 3    [   ] 4    [   ] 5 No
 
[  ]  This is well written and helpful.
[  ]  It may not win the Pulitzer Prize, but it does the job.
[  ]  There are shortcomings, but it is usable.
[  ]  I found it hard to understand some key concepts.
[  ]  Readability seriously interferes with the purpose of this 
      document. This really needs to be rewritten before it is released.


10. What do you think the Schema WG should do:

[  ]  Ship as soon as possible, without significant change.
[  ]  Ship as soon as possible, making the prose more readable, 
      but without changing the design of schema itself.
[  ]  Keep the current feature set, take one more shot to improve 
      both the design of schema and the prose.
[  ]  Simplify the feature set, take one more shot to improve both the 
      design of schema and the prose.

11.  If the Working Group were to spend time redesigning Schema, 
what do you think we should spend our time doing?

12.  If you feel the Working Group should continue working on Schema, 
how long would you be willing to wait for an improved version of XML Schema?

[  ]  Shoot the engineer and ship it now!
[  ]  6 months
[  ]  12 months
[  ]  18 months
[  ]  24 months

Last Modified Date: 07/14/2000 16:06:08