(Martin Bryan to XML Schema comments list, 29 February 2000.)

There would appear to be no mechanism for entering a data prior to 0 AD. Could -CCYY be allowed, with the proviso that 0000 is not a valid year?

(Paul Cotton to XML Schema comments list, 9 March 2000)

The spec should specify the legal value ranges of the CC, YY, MM, and DD parts of a date (even if this information is given in ISO 8601), and also the various parts of a time value.

"C. M. Sperberg-McQueen" <cmsmcq@acm.org> to XML Schema Comments list, Mon, 08 May 2000 20:11:05 -0600

At 16:24 00/02/29 +0000, Martin Bryan wrote: There would appear to be no mechanism for entering a data prior to 0 AD. Could -CCYY be allowed, with the proviso that 0000 is not a valid year?

I believe that this form is allowed by the schema spec. Section 3.3.24.1 says

"To accommodate year values outside the range from 0 to 9999, additional digits can be added to the left of this representation and an preceding '-' is allowed."

I believe there are two typos here (there is no year 0 in the Gregorian calendar, so the range should be 1-9999, and for 'an' read 'a'), but the phrase about the preceding minus sign is not a typo.

Personally, I agree that there should be a note pointing out that '0000' is not a valid year; otherwise, too many implementors will get it wrong.

"Martin Bryan" <mtbryan@sgml.u-net.com> to XML Schema Comments list on Sun, 14 May 2000 08:01:08 +0100

Ashok

You have sent a number of notes with comments on the Datatypes part of the XML Schema specification. We appreciate your input. I believe I have responded to all your concerns but would like to ask you formally whether you feel your concerns have been addressed and the issues you raised can be closed.

The vast majority of my concerns have been answered, for which I thank you. There are still some relatively minor ones, such as the sentence that reads 'To accommodate year values outside the range from 0 to 9999, additional digits can be added to the left of this representation and an preceding "-" is allowed.' This really needs the 0 changed to 1, and a statement to indicate that negative numbers represent Before Christian Era (BC/BE) dates....

Curt Arnold to XML Schema Comments list, 3 March 2000:

The following facets would seem to address quite a few constructs that appear within Schema for Schema and a few things like multiple, disjunctive value ranges from http://lists.w3.org/Archives/Public/www-xml-schema-comments/1999OctDec/0034.html

Examples:

(Paul Cotton to XML Schema comments list, 9 March 2000)

1. Section 2.4.1.2 Order

This section states "In such cases each datatype will define a different order relation on the value space". I do not understand why this must be done. Certainly at worst it should say "may define". Better even would be to delete the sentence entirely.

(Paul Cotton to XML Schema comments list, 9 March 2000)

2. Section 2.4.2.5 enumeration

This section states "No order or any other relationship is implied ...". This seems to imply that enumerations are not ordered. I think this sentence needs to be reworded to imply that "No further ordering is implied" since certainly the ordering of the underlying data type must be inherited. If not then XML Query will have no means of ordering enumerations.

(Paul Cotton to XML Schema comments list, 9 March 2000)

3. Section 3.2.1 string

This section states "The ordered property of string is the Unicode character number sequence." The string data type is the only primitive datatype that makes an explicit statement about how the ordering relation (not property) is defined. I expect the ordering information is missing from other primitive datatype sections.

(Paul Cotton to XML Schema comments list, 9 March 2000)

4. Section 3.2.1 string This section states "The ordered property of string is the Unicode character number sequence." I wonder why the definition of the string datatype does not permit a user to define the "collation" to be used? "Unicode character number sequence" is only one "collation" and is not very useful. In addition the specification does not explain why this "collation" is needed.

XML Query will need to support different collations for the string data type. It would be preferable if the collation was defined as part of the <data type> not as part of the query <predicate>s. I would recommend you consider a solution such as one adopted by SQL to permit the type definer to simply name the collation to be used. No exact definition of the action collation needs to be provided since there are several other sources for this information.

(Paul Cotton to XML Schema comments list, 9 March 2000)

5. Section 3.2.5 decimal

The Note in this section asks "Our design discussions did not reveal convincing evidence of undue burden because of arbitrary precision decimal numbers in this design, but we welcome further input from implementors".

I believe that you may want to consider the impact on implementors of a query language based on this data type that must implement <predicate>s and arithmetic operators for an "arbitary precision decimal number". I believe we will find this to be too expensive and that implementations will in fact constrain the precision of this data type. If the XML Schema specification does not do this then interoperability will be heavily constrained.

I do not accept the argument that XML Schemas needs an arbitrarily precise decimal datatype just to be able to model the length of names in XML which are in turn unconstrained in length.

I suggest that the document be modified to state that the maximum precision for decimal numbers should be an "implementation-defined number not less than X" where X can be agreed upon by implementors as a practical lower limit for this amount. "Implementation-defined" means that a conforming implementation must state in its conformance statement what the value is.

(Paul Cotton to XML Schema comments list, 9 March 2000)

6. Section 3.3.9 integer

The definition of the lexical representation of the integer datatype does not correctly reflect that non-significant leading and trailing zeroes should not be used. Non-significant zeroes are leading zeroes to the left of the decimal point or trailing zeroes to the right of the decimal point. I suggest using this concept in the descriptive material.

(Peter Canning to XML Schema IG, 14 March 2000 -- member-only)

[What if I want a type 'ASCII' or 'Latin1', to model an existing string type?]

(Mary Fernandez to XML Schema Comments list, 15 March 2000)

I am writing as a representative of the XML Query working group. Currently, we are specifying the data model for XML Query. Part of that exercise requires specifying formally the mapping from an instance of the PSV Infoset to an instance of the Query data model.

This message regards the definition of the Schema Infoset Contribution for Identity-constraint tables described in : http://www.w3.org/TR/xmlschema-1/#Identity-constraint_Definition_details.

This message has 2 parts:

Part 1.

A request to review the example in the attached text file. Please confirm that this example is correct w.r.t. the definition above.

If not, please explain how we misinterpreted the definition.

The attached example contains an abbreviated version of the <purchaseReport> example by David Fallside in : http://www.w3.org/XML/Group/xmlschema-current/new-design/exposition.html.

For the given example, we define a fragement of the corresponding PSV Infoset instance, which contains the Identity-constraint table for the <purchaseReport> element item.

We use the following notation:

Here's a DTD for an identity-constraint table that I inferred from the XML Schema document:

Part 2

A question and a suggestion follow.

In the subsection "Schema Information Set Contribution: Identity-constraint Table", I believe "key sequence k" should be changed to "key sequence b". If not, then please explain the relationship between the b & k key sequences.

[On 17 March 2000 Henry Thompson replies: You're right about the typo, that should be 'key sequence k' throughout."]

Part of the difficulty in understanding the definition of the Identity-Constraint table is that the document tries to describe in prose both what the table is and how to construct it at the same time. I tried to translate the prose into a pseudo-code specification (see below). If we assume that a node table is is a table of (key-sequence, qualified-node) pairs and is keyed on key-sequence, we can compute a new node table for element E, eligible constraint C as follows:

You might not want to present the definition in such a form, but for anyone who must implement or use the Schema definition (such as the Query working group), this is precisely what must be inferred.

[On 5 April 2000, Henry Thompson replied: "As near as I can tell your algorithm is correct, and the example infoset is also correct."]

A. Abbreviated Example Data (same Schema as in full example)

B. Information-Set Instance for Example Data in A. This is an XML serialization of the infoset instance.

(Aram Airapetian to XML Schema Comments list, 30 March 2000)

How come the date and the time types have the same period? The "000000T2400" value is period for time. It is 'unit' for date, though. For date (CCYY-MM-DD, see 3.3.22.1) period is "010000". Am I missing something?

The notions of 'period' and 'unit' might be beneficial for simplification of numeric type definition. All types 3.2.2 - 3.2.5 and 3.3.9 - 3.3.21 could be defined (derived from decimal) by assigning corresponding 'period', 'unit' and 'signed/unsigned' constraints.

My apologies for taking so long to reply to your note below. We have made some changes to the text and corrected some typos. Now, "date" has a period of 0 (no recurrence) and a duration of 24hours. "time" has a period of 24 hours and a duration of zero. I trust that addresses your concerns.

(Aaron M. Cohen to XML Schema Comments list, 3 April 2000)

It has recently been brought to my attention that the current draft of XML-Schemas does not provide a mechanism for incrementally building up an attribute set on an element, perhaps from several separate modules containing attributes, and also for adding attributes to elements already declared.

This is essential for modularizing SMIL with XML Schemas, and is something that can (and has) already be done with DTD's. Maybe my information is incorrect, or my understanding is faulty, so I am sending this to make you aware of our needs, and asking for guidance in applying XML Schemas in this manner. If my information and understanding are correct, then please consider this a requirement for the SMIL modules to have associated XML Schemas. I am under the impression that XHTML has very similar needs, and my impression is based in part on my exchanges with some of the XHTML folks.

A concrete example will probably make our needs clear. So I'll discuss our modularization needs in the context of a vastly simplified view of SMIL.

SMIL timing is a set of reusable modules that can be used to incorporate timing relationships into XML languages. This language could be "SMIL", or "XHTML", or something else. We provide time containers, which are grouping elements that contain other elements and provide semantics for the timing relationships between the grouped elements. We also provide attributes that are added to elements to allow authors to specify explicit timing relationships.

For example, SMIL includes the parallel time container, <par>, which allows for several things to be played at once. To play an audio and video clip and the same time (assuming that the language, like SMIL 1.0, includes elements to express playing each of these):

Note that the elements could be from some other language, such as XHTML. Here's how two paragraphs of text might be displayed at the same time:

This becomes much more powerful when the elements that are timed can have their own timing-specific attributes. For this discussion, we'll only have two. 'begin' tells when to start displaying something, and 'dur' specifies the duration, or how long to display it. Building off the XHTML example:

This displays the first paragraph immediately for 1 second, then there is one second where nothing is displayed, and then at time=2s, the second paragraph is displayed for 1 second.

This admittedly very simple example gets to the root of what we need to be able to accomplish with XML Schemas. The <p> element is already defined in a module by XHTML. For a language designer to be able to incorporate or combine timing with elements already defined, we need to be able to extend the attribute set of an element defined in a different module. For this particular example, the language designer needs an XML Schema method of adding the begin and dur attributes defined in a SMIL XML Schema module to the <p> element defined in an XHTML Schema module. It is not sufficient to just be able to declare the members of an attribute set from several places when the element is initially defined.

Please feel free to contact me with any questions you may have about anything that I have said here.

Dan Connolly <connolly@w3.org> to XML Schema Comments list on Fri, 12 May 2000 17:18:11 -0500

It has recently been brought to my attention that the current draft of XML-Schemas does not provide a mechanism for incrementally building up an attribute set on an element, perhaps from several separate modules containing attributes,

I believe the attribute group mechanism provides this. http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/#Attribute_Group_Definition

and also for adding attributes to elements already declared.

I presume you're talking about this idiom...

"6.1. Defining additional attributes [...] This works because XML permits the definition or extension of the attribute list for an element at any point in a DTD. " http://www.w3.org/TR/2000/WD-xhtml-building-20000105/developing.html#s_dev_attrs

The Schema spec provides an analog of this idiom; if you want your element declarations to allow other attributes this way, just include

cf http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/#element-anyAttribute

I would actually recommend ##other rather than ##any; requiring "mixed in attributes" to be declared as coming from another namespace seens more appropriate than allowing unqalified attributes or attributes from the same namespace.

This is essential for modularizing SMIL with XML Schemas, and is something that can (and has) already be done with DTD's.

Well... it can be done with a specific set of conventions layered on top of DTDs, using parameter entities. It cannot be done for arbitrary combinations of DTDs. And the XHTML modularization mechanisms are susceptible to name collisions between modules.

cf http://www.w3.org/TR/2000/WD-xhtml-building-20000105/developing.html#s_dev_attrs

Maybe my information is incorrect, or my understanding is faulty, so I am sending this to make you aware of our needs, and asking for guidance in applying XML Schemas in this manner. If my information and understanding are correct, then please consider this a requirement for the SMIL modules to have associated XML Schemas. I am under the impression that XHTML has very similar needs, and my impression is based in part on my exchanges with some of the XHTML folks.

A concrete example will probably make our needs clear.

Yes, thanks.

So I'll discuss our modularization needs in the context of a vastly simplified view of SMIL.

SMIL timing is a set of reusable modules that can be used to incorporate timing relationships into XML languages.

I started drafting a schema for SMIL animation; see: http://www.w3.org/XML/2000/04schema-hacking/smil-animation.xsd, revision 1.1, date: 2000/05/04 19:35:09, aka http://www.w3.org/XML/2000/04schema-hacking/smil-animation.xsd.txt

This language could be "SMIL", or "XHTML", or something else. ...

This admittedly very simple example gets to the root of what we need to be able to accomplish with XML Schemas. The <p> element is already defined in a module by XHTML. For a language designer to be able to incorporate or combine timing with elements already defined, we need to be able to extend the attribute set of an element defined in a different module.

Or, alternatively, you need the definition of the P element to allow attributes declared elsewhere (as noted above, this is the default in XML 1.0)

I mocked up this example... http://www.w3.org/XML/2000/04schema-hacking/h+s.html

(The schemaLocation gobbledygook is only necessary until schemas for XHTML and SMIL are available by dereferencing their namespace identifiers)

then in html.xsd: (i.e. http://www.w3.org/XML/2000/04schema-hacking/html.xsd)

and in smil-animation.xsd :

You can check the results using http://cgi.w3.org/cgi-bin/xmlschema-check i.e. http://cgi.w3.org/cgi-bin/xmlschema-check?docAddrs=http%3A%2F%2Fwww.w3.org%2FXML%2F2000%2F04schema-hacking%2Fh%2Bs.html

I have used qualified names for the "mixed in" attributes, per this principle:

"The syntax must unambiguously associate an identifier in a document with the related schema without requiring inspection of that or another schema." -- http://www.w3.org/TR/1998/NOTE-webarch-extlang-19980210#Ambiguity

The schema spec allows you to violate that principle by using <anyAttribute namespace="##any"/> on the P element declaration, and and attributeForm="unqualified" in the smil-animation schema, but I don't recommend that.

For this particular example, the language designer needs an XML Schema method of adding the begin and dur attributes defined in a SMIL XML Schema module to the <p> element defined in an XHTML Schema module.

I believe I have demonstrated this above.

It is not sufficient to just be able to declare the members of an attribute set from several places when the element is initially defined.

... To this end, we need confirmation that it can be done with XML Schemas, and guidance in how to proceed.

Does the explanation above provide enough confirmation and guidance?

I've been told to expect a note on modularization using XML Schemas. Will our use cases be covered in that note?

I'm not sure.

"Cohen, Aaron M" <aaron.m.cohen@intel.com> to XML Schema Comments list on Mon, 15 May 2000 15:31:05 -0700

Dan:

Thanks for taking a look at this. I'll take a closer look at your SMIL Animation Schema later this week when I have a chance.

Meanwhile, I have a question. You integrated the SMIL timing attributes with the "P" element by making your own version of xhtml.xsd that allowed including qualified attribute names from other schemas. I'm not sure that this is a total solution.

However, in my understanding of our discussion of namespaces, I got the impression that redefining elements to include new content and/or attributes and then "putting" those elements in a "new" namespace was okay. So it seems that you can define hybrid languages, it's just that they don't have a "lineage" reflected in a namespace structure, or in an XML Schema structure (because the attributes on an element can only be defined in one place).

This will lead to integrations that need to be done very differently in DTD's vs. XML Schemas. What I mean is that in some cases, the schema will have to repeat a lot of stuff defined in a "base" schema, while the DTD will not. The case in point is XHTML+SMIL, which it seems, will have to repeat the definitions of all of the XHTML-based elements, add the timing attributes (which can be done nicely in attribute groups in the smil modules), and declare them in a new namespace. So while there will be very tight semantics coupling between XHTML and XHTML+SMIL, this coupling will not be reflected in either the namespace or the schema for XHTML+SMIL.

About the best that I think could be done is if the XHTML-WG creates "proto-HTML" types that can be used in the derived languages to define the actual elements.

I think that you can do something like this for timed <a> link's (correct me if I am wrong):

In the XHTML.xsd:

In the SMIL.xsd:

And then in the XHTML+SMIL.xsd:

Of course, the means to do this has to be set up in XHTML.xsd and SMIL.xsd. I can see us doing this kind of thing for SMIL, but of course the other stuff is up to XHTML, SVG, and the other XML-based languages using XML Schemas.

Meanwhile, I have a question. You integrated the SMIL timing attributes with the "P" element by making your own version of xhtml.xsd that allowed including qualified attribute names from other schemas.

Yes, I expect the "official" XHTML schema to work that way.

I'm not sure that this is a total solution.

However, in my understanding of our discussion of namespaces, I got the impression that redefining elements to include new content and/or attributes and then "putting" those elements in a "new" namespace was okay. So it seems that you can define hybrid languages, it's just that they don't have a "lineage" reflected in a namespace structure, or in an XML Schema structure (because the attributes on an element can only be defined in one place).

Not so: (a) as I say, I expect the XHTML schema to allow anyAttribute namespace="#other" in the first place, and (b) if you did create a new XHTML namespace, you certainly could design it so that it has a discoverable "lineage", i.e. it derived from the canonical XHTML schema.

This will lead to integrations that need to be done very differently in DTD's vs. XML Schemas. What I mean is that in some cases, the schema will have to repeat a lot of stuff defined in a "base" schema, while the DTD will not.

I don't know what leads you to think that; it's not so.

The case in point is XHTML+SMIL, which it seems, will have to repeat the definitions of all of the XHTML-based elements, add the timing attributes (which can be done nicely in attribute groups in the smil modules), and declare them in a new namespace. So while there will be very tight semantics coupling between XHTML and XHTML+SMIL, this coupling will not be reflected in either the namespace or the schema for XHTML+SMIL.

About the best that I think could be done is if the XHTML-WG creates "proto-HTML" types that can be used in the derived languages to define the actual elements.

I certainly expect the HTML WG to use things like <anyAttribute namespace="#other"> to specify that XHTML is extensible.

I think that you can do something like this for timed <a> link's (correct me if I am wrong): ...

Yes, that's another way to design a schema for XHTML+SMIL.

But I hope that we don't use that approach; as you say:

Of course, the means to do this has to be set up in XHTML.xsd and SMIL.xsd. I can see us doing this kind of thing for SMIL, but of course the other stuff is up to XHTML, SVG, and the other XML-based languages using XML Schemas.

I think it's clearly preferable to have one schema for XHTML, one for SMIL, one for SVG, and one for MathML that can be used together in compound documents; rather than one for XHTML+MathML, one for XHTML+MathML+SVG, etc. for a total of N! schemas.

(Aaron M. Cohen to XML Schema Comments list, 3 April 2000)

The same thing goes for the content model of the elements. It may be necessary to extend the permissible child element set of a module beyond how it was initially defined. SMIL Boston is planning on using "levels" of modules. As the functionality goes up in higher levels, we add some elements to the set of allowed children. As above, we'll also add new attributes to existing elements in order to make them more powerful in the higher level modules.

Furthermore, we will use the above process to define our next version of the SMIL Language, and also to define a language/profile that combines XHTML and SMIL timing structure (as well as some other aspects of SMIL), and to define a baseline "SMIL-Basic". So you can see that the use case that we are asking for is a key element in SMIL being a successful and reusable technology. The DTD experts in the group are comfortable that we can produce DTD's that reflect this structure, and we would also like to have a set XML Schemas before SMIL becomes a Recommendation. To this end, we need confirmation that it can be done with XML Schemas, and guidance in how to proceed. I've been told to expect a note on modularization using XML Schemas. Will our use cases be covered in that note?

Please feel free to contact me with any questions you may have about anything that I have said here.

(Curt Arnold to XML Schema Comments list, 6 April 2000)

It would seem a minimal burden to add a built-in datatype that allows you to declare an attribute (or element content) as conceptually being an XPath. Since XPath is intended to be used across W3C technologies, it would seem that the best place for it would be as a built-in type in Schema instead of every technology that uses it trying to kludge it with their own regular expressions.

The difficulty is in the implied validation a schema aware processor is expected to do when it encounters an attribute that uses an XPath or derived datatype (in the same manner the parser is anticipated to validate that a uri or Qname is valid beyond what is in the explicit Schema for Schema definitions). If that seems like too much complexity, you could except conforming processors from doing any implied validation of XPath's. But compared to the overall complexity of Schema, an XPath type validation seems fairly trivial.

(Curt Arnold to XML Schema Comments list, 6 April 2000)

I meant to mention this at XTech, but it may be useful to allow for element and attribute a way that a user agent could obtain an initial or hint value for an element or attribute that didn't add anything to the information set. Possibly something like:

When initial is specified, a user agent may use it to provide a initial value for a user interface field, but an XML processor doesn't use it to provide a value if it isn't specified.

This could result in a Schema generated UI having a quantity field with initialized to 1, but would not result in:

being interpreted as having a quantity of 1.

Explicitly supporting this hint in XML Schema might make things a little cleaner with XForms which is using default to mean what I called initial.

(Martin Duerst to XML Comments list, 7 April 2000)

On the XML schema side, if it's currently not possible to express arbitrary order with occurrence constraints, that may be a problem independent of whether P3P needs it; I'm sure there are other uses where this is a requirement.

"Yuichi Koike" <koike@w3.org> to XML Schema Comments list, Tue, 18 Apr 2000 14:00:30 -0400

Though P3P WG decided to have fixed the element order in P3P 1.0 spec, we would like XML schema to have the ability to express arbitrary element order in a compact form.

And the answer to the following question is "Yes".

At 00/04/04 22:12 +0100, Henry S. Thompson wrote:

If what you want is arbitrary order, just what do you mean by that, e.g. , is the following OK?

The above question is pressing, if you want the WG to consider "arbitrary order with occurrence constraints", we really need clear input on this.

(TAMURA Kent to XML Schema Comments list, 10 April 2000)

I have some comments on the regular expressions section in the last call draft.

Re: The entire It is hard to know concrete syntax of the regular expression from the draft. I want readable rules like BNF.

Alexander Falk to XML Schema Comments list, 11 April 2000

I would certainly also hope to see a compact EBNF description for the Regular Expressions in the final draft - for the time being I have created my own condensed version for use in our own development, which I'll gladly share with you:

(TAMURA Kent to XML Schema Comments list, 10 April 2000)

Re: Character class subtraction E.1:

[Definition:] A character class subtraction is a character class expression subtracted from a positive character group or negative character group, using the - character.

This definition does not explain how to use '-'. The next paragraph says "G-C is a valid character class subtraction", but there are no restriction on other usages of '-', like "GC-", "-GC" :-)

(TAMURA Kent to XML Schema Comments list, 10 April 2000)

Re: '-' in character range A '-' in a character class has many meanings. So, interpretation of '-' can be ambiguous. For example:

We can interpret this character class as:

(TAMURA Kent to XML Schema Comments list, 10 April 2000)

Re: Definition of multi-character escape: "\w" is defined as "[&#x0000;-&#xFFFF;]-[\p{P}\p{S}\p{C}]", but both of &#x0000; and &#xFFFF; are invalid character references in XML. I don't know characters in &#x10000;-&#x10FFFF; should be in "\w".

(David RR Webber to XML Schema IG, 2 May 2000 -- member only)

[This is of immense importance: many people live their lives organized around non-gregorian calendars. A neutral date-time code (e.g. days and seconds since some epoch) would solve the problem.]

(Murray Altheim to XML Schema IG, 5 May 2000 [member only])

[A glossary would be a big help.]

"Joseph M. Reagle Jr." <reagle@w3.org> to XML Schema Comments list on Wed, 10 May 2000 12:48:14 -0400

Glossary; and Model Groups, Model Group Definitions, and Element Declarations

I find the distinction between these things confusing, perhaps it could be simplified or more text could be spent on describing how these things are different. Actually, I look forward to the glossary being completed as this will help me in understanding the specification. See http://lists.w3.org/Archives/Public/xmlschema-dev/2000Apr/0021.html for more:

("Falk, Alexander" <falk@icon.at> to XML Schema Comments list, 10 April 2000)

I was studying the new April 7 version of the XML Schema working draft throughout the weekend, as we are in the process of finalizing the beta 3 version of XML Spy 3.0 (see http://www.xmlspy.com/version30.asp), and I have a first list of comments and questions - especially regarding the changes to the datatypes (part 2).

Part 1 - Structures

A. Schema for Schemas

Why does the Public Identifier URN for the DOCTYPE statement still use 19991216 as its date, when the DTD for Schemas (Appendix B) is v1.1 dated 2000/04/06. This Public Identifier URN seems to imply that the Schema for Schemas is itself written in compliance with the old December 1999 XML Schema draft, which it is not.

Along the same lines: the year in the XML Schema namespace URI is also still fixed with 1999 - is that going to change for the final recommendation? While it is understandable from an implementors point of view that the URN should remain constant over the time of the draft and recommendation creation, it would IMHO be rather confusing for all future schema authors, if the date given here is not identical to the date of the final recommendation.

("Falk, Alexander" <falk@icon.at> to XML Schema Comments list, 10 April 2000)

G. Tabulation of Changes The comments in this list are not very useful at all. Compared with "H Revisions from previous draft" in Part 2, which is ideal for implementors and saves us the burden of re-reading the entire Specs again and again, the list of changes in Part 1 is too minimal. Comments like "Lots of edits" or "more from Noah" are simply not comprehensible without the background that only insiders of the WG can have. Please provide a more meaningful change history in the future (or none at all).

("Falk, Alexander" <falk@icon.at> to XML Schema Comments list, 10 April 2000)

Part 2 - Datatypes

3.2.2.2 Constraining facets on boolean datatype Other than specifically restricting the lexical space to either {0,1} or {true, false} for a certain schema, what is the intention of allowing a pattern facet for booleans?

("Falk, Alexander" <falk@icon.at> to XML Schema Comments list, 10 April 2000)

3.2.8.1 Constraining facets on binary datatype As binary currently only offers two different encodings that specify the respective lexical spaces, defining a pattern facet on binary doesn't make much sense - other than e.g. restricting the letters a-f to uppercase-only or lower-case only. However, with base64 the alphabet is strictly defined in the RFC. To answer the question contained in the Ed.Note of this chapter, I would, therefore, suggest to omit the pattern facet here from an implementors standpoint, as its benefits are rather limited and the potential confusion would be worse.

("Falk, Alexander" <falk@icon.at> to XML Schema Comments list, 10 April 2000)

3.2.3 - 3.2.5 Lexical notation of floating-point numbers While it is very nice from an implementor's standpoint to know that all sorts of float, double, or decimal numbers will only use the period as a decimal separator, I wonder if this is really satisfying for many European and other non-US users. Specifically, when XML is being used to supplant existing systems, it is often necessary to interpret floating-point or decimal number with other decimal separators (most notably ',') and in some cases also including thousands separators (e.g. 4,560,758.99 vs. 4.560.758,99). Why is there no means provided to support these formatting styles in the XML schema draft. Just like the encoding facet for binaries, this "formatting" or "picture" facet (to use an old COBOL-coined term that was also suggested in the DCD submission to the W3C in July 1998) could be used to specify the various aspects of the lexical space of these datatypes. If we were to consider XML schemas for B2B e-Commerce scenarios only, it would be understandable to only allow one format that can be easily processed - but XML schemas should be thought of in much broader terms.

"Dario de Judicibus" <ddj@mclink.it> to XML Schema Comments list, Tue, 25 Apr 2000 23:12:02 +0200

Similarly we might define a new facet for decimal, dates, and other locale based data types, to support locale format. For example

The derivation by format means that we do not restrict the scope of type, but we work on the lexical representation.

Curt Arnold <carnold@houston.rr.com> to XML Schema Comments list, Wed, 26 Apr 2000 07:56:59 -0500

Localized numerical representations: The lexical representations were chosen for their unambiguity. For instance, the timeInstant format is an undesirable presentation format in all locales. In general it is assumed that localization of presentation would be done in transformations or applications. Definitely, wanted to avoid the case of not being able to determine (or worse guessing) whether a comma was a digit separator or a decimal point. You could create an italian decimal as a derived class from string, however min/max would be interpreted as string comparisions.

dejudicibus@it.ibm.com to XML Schema Comments list, Thu, 27 Apr 2000 12:35:14 +0200

Thank you for your reply, Curt. I still have a doubt about the localization issue, anyway. You said:

"Definitely, wanted to avoid the case of not being able to determine (or worse guessing) whether a comma was a digit separator or a decimal point."

I understand your point. However I am wondering the following. Let us suppose that you defined a language for legal documents which states that numbers are xsd:decimal and dates are in user-defined typical US format (MM/DD/YY). An Italian company publishes in its site a contract for web ordering of products. The contract uses that language and contains a price EUR 8.500 and a date 03/04/01. For that company, the price is eight thousand and five hundreds euros, and the date is April 3rd, 2001, but for an American customer price is eight euros and fifty cents, and date is March 4th, 2001. It would be very useful if the browser would be able to automatically convert those value to the current locale, that is the locale of customer. This is possible anyway, only if the webmaster specified in the document the locale in which those values had been written.

If you fix the format of decimal in XML Schema, you force me to use US-like format in Italian pages, or not use your language at all. That is, instread of

which contains a US-form price, I will have to use

hoping that product content is defined as mixed. I would prefer

As you can see, there is no need to change the meaning of decimal, but rather adding a new attribute for XML languages, and add in xsd:complexType a new property called xsd:localisable or something like that:

("Falk, Alexander" <falk@icon.at> to XML Schema Comments list, 10 April 2000)

3.3 A general question concering constraining facets in derived types: Most of the derived datatypes have certain facets that distinguish them from the primitive types. However, each one of the derived types still lists the very facets that were used to generate it from the primitive types in its list of applicable constraining facets. Consider the case of recurringDay, which is derived from recurringDuration by fixing the duration facet with "PT24H" and the period facet with "P1M". This type still lists duration and period as possible constraining facets - yet they are absolutely fixed by the very definition of recurringDay. How should a validating processor treat a new type derived from recurringDay that actually tries to use one of these facets in its definition? I see two possible solutions to this dilemma:

"Martin Bryan" <mtbryan@sgml.u-net.com> to XML Schema Comments list, Thu, 13 Apr 2000 12:15:46 +0100

Another, unrelated, problem concerns the your listing of scale as a valid facet for integer based derived datatypes. Under what conditions is it valid to specify a scale property for an integer?

("Falk, Alexander" <falk@icon.at> to XML Schema Comments list, 10 April 2000)

3.3.29.1 Lexical representation of recurringDay If this is a left truncated ISO-8601 day, then it should be ----DD, not ---DD.

("Falk, Alexander" <falk@icon.at> to XML Schema Comments list, 10 April 2000)

A. Schema for Datatype Definitions The part.xsd schema document includes the namespace " http://www.w3.org/XML/1998/namespace" from a schemaLocation "../structures/xml.xsd" yet I was unable to locate this file on the W3C web-server. Can you please provide a URL that will allow me to access the xml.xsd file?

"Arnold, Curt" <Curt.Arnold@hyprotech.com> to XML Schema Comments list, Wed, 12 Apr 2000 10:32:39 -0600

Microsoft IE5 complains about xmlns:x not being fixed in the following line in Part2.xsd:

My interpretation is that the parser's behavior is well-intentioned but wrong. However since the line is in the DTD for compatibility to begin with, changing the line to:

should preserve compatibility with the most ubiquitous XML parser.

("Falk, Alexander" <falk@icon.at> to XML Schema Comments list, 10 April 2000)

Would it be possible for a future draft or the final recommendation to include one downloadable archive file (ZIP, gzip, or any other common formats) that includes all required files in one neat package (i.e. the specs and their respective DTDs and XSL files plus the non-normative Schema DTDs, XSDs, and any other required file).

("Falk, Alexander" <falk@icon.at> to XML Schema Comments list, 10 April 2000)

E. Regular Expressions For an implementor's position I don't see why defining {,m} as a shorthand form of {0,m} would be a problem. It would seem logical to add this, now that {n,} is allowed. I don't think it is relevant whether or not Perl includes such a quantifier. If it is more consistent and could potentially help schema authors, then it should be added.

("Falk, Alexander" <falk@icon.at> to XML Schema Comments list, 10 April 2000)

Along these same lines: I doubt that there is any meaningful use for {0,0} apart from effectively "commenting out" the preceding atom. Furthermore, {0,0} could then potentially be written as {,} which is even more confusing. Apart from being a logical consequence of the {n,m} quantifier, what was the reason for adding {0,0} to the table as a separate line?

("Falk, Alexander" <falk@icon.at> to XML Schema Comments list, 10 April 2000)

Another problem: it is currently impossible to define a pattern that uses the vertical bar '|' as a character, because this is defined as a separator between branches, and there is no single character escape defined for \|. The only workaround is to include the vertical bar inside of a positive character group in a character class escape: [|]. Wouldn't it be better (i.e. more consistent) to add \| as a single char escape?

David Wang <dwang@mitre.org> to XML Schema Comments list, Mon, 10 Apr 2000 16:06:09 -0400

I think the example for xmlschema-0/Section 5. Advanced Concepts III: The Quarterly Report has a small typo in either 4Q99.xml or report.xsd because the XML uses

while the schema says it should be

I think the schema is the one that has the typo.

Ray_Gates@manulife.com to XML Schema Comments list, Tue, 18 Apr 2000 16:17:26 -0400

In section 5 Advanced Concepts III: The Quarterly Report, in the listing of report.xsd:

under

If I am reading this correctly, this should be

to be consistent with references to this element.

David RR Webber <Gnosis_@compuserve.com> to XML Schema Comments list, Tue, 11 Apr 2000 11:34:51 -0400

... the current W3C Schema work is fundamentally flawed and does not provide a functional system that can support broad eBusiness interchanges in the same way that X12 and EDIFACT have provided for EDI. There are too many omissions, too many shortcomings and not enough regard to basic usability.

... The requirements fail to encompass what is now transpiring with ebXML, eCo and eSpeak to name some. Then a simple review of industry initiatives such as FIXML, wfmXML, RosettaNet, show the need for eBusiness directed mechanisms that are just not being addressed. Again, the requirements for Schema were written nearly two years ago - it's time to address this and revisit the requirements in the context of 2000/2001 and eBusiness needs.

All this is documented at http://www.bizcodes.org/eDTD/xml-eDTDWP.htm.

1) Moratorium of 3 months to allow Schema Specifications to be re-visited, particularly in the context of ebXML technical requirements.

2) 3 Tier syntax strategy to be adopted that allows hierarchy of representational levels -

3) Field testing for 6 months prior to formal adoption, with selection of industry groups providing evaluations, not just a set of vendors.

4) Interoperability test-suite development to ensure consistency.

Of course there are issues with this - but nothing that cannot be resolved by setting working parameters and putting together a cross-management group to oversee the technical work. We have plenty of precedence for this with efforts like RosettaNet and the standards groups X12, HL7, EDIFACT, et al. Yes this takes time, but this is one instance when that's exactly the path we should be taking now.

I'd rather have an objective Schema system that has been developed with broad involvement, rather than spending the next several years fixing up an inadequate system.

History teaches us that EDIFACT's semantics are much cleaner than X12's because X12 is a hodgepodge that evolved in an adhoc fashion. Right now we are looking at history repeating itself - and ebXML is our one bright hope to ensure that two years from now we're not looking at a dozen variants of XML/edi - all of which are not interoperable.

("Bruce Peat" <BPeat@eProcessSolutions.com> to XML Schema Comments list, Wed, 12 Apr 2000 16:06:53 -0400)

As to the 'three month timeframe', I think the members of the W3C should decide the schedule. This hierarchy approach should allow the working group to concentrate on what constitutes the 'base', and consider what best makes sense for the other 'representational levels'. As you suggest, this would give us more time to work and prove the extensions before going to recommendation status following a period of time after we can a chance to begin implementation using the base recommendation.

This approach I think would be accepted with open arms in the community. For a recommendation with a larger scope and without proper constraints for exchange would force a subset of the specification to be used in industry and will keep the various non-interoperable implementions on other critical items. IMHO: The W3C decision here could either save or cost industry billions of dollars over the next few years.

David RR Webber <Gnosis_@compuserve.com> to XML Schema Comments list, Wed, 12 Apr 2000 16:45:03 -0400

Ani Pedersen <APeders@plexus.ca> to XML Schema Comments list, Tue, 11 Apr 2000 14:22:40 -0700

I have just started digging into XML and I need some help regarding mutiple field keys.

The new XML schema - Structures does not give any solution in how to implement multiple field keys. The only comment in section 3.10 is a note that mentions that is not supported by xsl:key.

Is there an alternative way of defining multi-field keys? A workaround?

Maybe I am missing something?

This is an extract of what I am working on and I need to define two fields as key values (they have to be together). Unfortunately the structure I came up with allows me to indicate that they both should be present and in that order (with group) and that both are keys. However, here I indicate that they are independent keys and I don't want that. Is there a way of restricting this looseness.

Ace <Ace@AceProgrammer.com> to XML Schema Comments list, Tue, 11 Apr 2000 16:42:00 -0700

I noticed that in the examples that are in XML Schema Part 0: Primer, that the comment element is usually defined:

The Primer explicitly says this means the element is optional. However, after looking at the spec and the explanation in the Primer, it seems to me that this actually makes the comment prohibited because it falls into the third case below. I hope I am mistaken. I'd rather the above syntax mean that the element is optional.

"Dario de Judicibus" <ddj@mclink.it> to XML Schema Comments list, Tue, 25 Apr 2000 23:12:02 +0200

Another problem is related to maxOccurs. It is said to be equal to minOccurs if not provided. But it is clear in specs that

means

and not

Is that a typo? Is intended?

Curt Arnold <carnold@houston.rr.com> to XML Schema Comments list, Wed, 26 Apr 2000 07:56:59 -0500

I believe that the maxOccurs issue was an oversight, has been reported here, and will be corrected.

berggren@lr.net (Peter A. Berggren) to XML Schema Comments list, Wed, 12 Apr 2000 10:54:16 -0400

Regarding the following extract from the last paragraph of Section 4.7 in XML Schema Part 0 : Primer...

"...As with final, there exists also an optional finalDefault attribute on the schema element whose value can be one of the values allowed for the final attribute. The effect of specifying the finalDefault attribute is equivalent to specifying a final attribute on every type definition and element declaration in the schema. ..."

This was apparently copied from a preceding, similar paragraph regarding finalDefault, without changing the word "final" to "block". I believe the text should read:

"...As with final, there exists also an optional blockDefault attribute on the schema element whose value can be one of the values allowed for the block attribute. The effect of specifying the blockDefault attribute is equivalent to specifying a block attribute on every type definition and element declaration in the schema. ..."

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 12 Apr 2000 15:56:40 +0100

Not key, but keyref, for a change.

Seems to me we missed a case: if the node picked out by a keyref's field is xsi:null='true', then this should be treated as if the node had not been found. As the PWD reads, it will just use an empty string as that field's contribution to the key sequence to be looked up.

Ditto for unique fields.

Your note of 4/12 confuses me. keyref fields can only refer to key fields and these are, by definition, non-nullable.

"Arnold, Curt" <Curt.Arnold@hyprotech.com> to XML Schema Comments list, Wed, 12 Apr 2000 10:05:26 -0600

Schema and DTD links in "This Version" header point to the Part 1 schema and DTD, not a text version of the schema or DTD for datatypes that I expected.

Section 3.3.22 time "date is generated from recurringDuration by setting the value of the duration facet equal to P0Y and the value of the period facet equal to PY24H (24 hours)."

I believe "date" should be "time".

Adrian Robert <arobert@dtai.com> to XML Schema Comments list, Wed, 12 Apr 2000 11:55:11 -0700

In the third paragraph in Section 3.1 (below), it appears that "qualified" should be changed to "unqualified". (Also, note there is a small agreement-related ungrammaticality in the 2nd sentence.)

"In po1.xsd we globally specify the qualification of elements and attributes by setting the values of both elementFormDefault and attributeFormDefault to qualified. Strictly speaking, this is unnecessary because these are the default values of the two attributes, but we do so to highlight the contrast between this case and others we describe in subsequent sections."

"Martin Bryan" <mtbryan@sgml.u-net.com> to XML Schema Comments list, Thu, 13 Apr 2000 12:15:46 +0100

I am trying to work out whether or not the derivedBy facet can be used to identify an element that contains a list of permitted values for an attribute. It seems to me to be a useful feature but I cannot see how it would work as the element referenced by derivedBy has, according to the Primer at least, and by implication from Part 2, to be in the instance and not in the schema. I was thinking about something along the following lines:

Is this valid? Where would MyCodeList need to be defined? (Is it permitted as part of the Schema?)

Incidentally the examples shown in Part 2 and the Primer conflict. Part 2 shows the use of the xsi:type attribute to link the instance to the derived type. The example in the primer does not include this attribute. Some clearer explanation of the role of this attribute and the position of the element containing the list of permitted values, might help to clarify this point.

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 13 Apr 2000 14:24:46 +0100

Confusion of levels/locations/facilities, I guess.

If you want to constrain element content, use an element declaration:

The <docroot> instance above is, as far as we can tell from the fragments given, schema-valid per the schema corresponding to the schema document above it.

If you want to constrain an element beyond its schema declaration in an instance, use xsi:type:

Again, the <docroot> instance above is, as far as we can tell from the fragments given, schema-valid per the schema corresponding to the schema document above it.

Neither of these examples define the restricted element type in the instance. To do that you have to play games with what amounts to an internal subset:

schema3.xsd:

"Martin Bryan" <mtbryan@sgml.u-net.com> to XML Schema Comments list, Thu, 13 Apr 2000 15:43:56 +0100

Thanks for the response, but you are on the wrong track. I see how constraining element content works quite nicely. The problem was that I specifically want to apply the same technique to an enumerated list of attribute values, hence my question:

I am trying to work out whether or not the derivedBy facet can be used to identify an element that contains a list of permitted values for an attribute.

The area I am trying to get working is the ebXML electronic business area. We have a lot of elements which have "qualifier" attributes whose values are taken from code lists. Ideally I would like to be able to "import" up-to-date codelists as part of the schema so that maintenance of the code list can be made independent of maintenance of the schema. Having to define such lists as enumeration lists is very long winded, so I would like to use the derived by method, but I don't see how it applies to attributes, hence my attempted example:

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 13 Apr 2000 18:03:06 +0100

What confuses me about your example is that you don't show an attribute in the instance, but rather an element. Your schema fragment, if it appeared within the type definition for the <banana> element, would schema-validate the following instance just fine:

Is what you want to be able to do is restrict the list elements to some enumerated list defined elsewhere?

"Martin Bryan" <mtbryan@sgml.u-net.com> to XML Schema Comments list, Fri, 14 Apr 2000 07:43:18 +0100

Yes, with a single value for the attribute taken from that list.

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 14 Apr 2000 11:27:45 +0100

Right, sorry not to have understood sooner. This is a request we've had before, and will certainly consider carefully.

"Martin Bryan" <mtbryan@sgml.u-net.com> to XML Schema Comments list, Thu, 13 Apr 2000 15:27:21 +0100

What does it mean to apply a pattern to a timeDuration?

Why does the example given of a timeInstance not have a Z before the last hyphen?

Why is the period facet of time shown as PY24H rather than PT24H? (Again there is no Z preceding the timezone details in the example.)

If you define a minInclusive or minExclusive date for a recurring duration whose period is 7 days will the days always fall on the same day of the week as the first date within the period (i.e. the minInclusive date)?

How can enumeration be applied to the binary datatype?

"Martin Bryan" <mtbryan@sgml.u-net.com> to XML Schema Comments list on Sun, 14 May 2000 08:01:08 +0100

You have sent a number of notes with comments on the Datatypes part of the XML Schema specification. We appreciate your input. I believe I have responded to all your concerns but would like to ask you formally whether you feel your concerns have been addressed and the issues you raised can be closed.

The vast majority of my concerns have been answered, for which I thank you. There are still some relatively minor ones, such as the sentence that reads 'To accommodate year values outside the range from 0 to 9999, additional digits can be added to the left of this representation and an preceding "-" is allowed.' This really needs the 0 changed to 1, and a statement to indicate that negative numbers represent Before Christian Era (BC/BE) dates. I would have loved to be able to deal with non-Gregorian calendars (e.g. Jewish, Arabic, Chinese, Japanese, Julian, ....) but don't expect everything to be in place at this stage.

The one area I still expect we are going to have problems in using datatype for electronic commerce is measurements. For example, how can I check that 100cm and 1m are exactly equivalent, but 1yd is not. But again I do not expect you to have addressed these problems at this state. (Schema2 will be along within a few years!)

Nevertheless you have done an impressive job and are to be highly commended.

"gmacri@libero.it"<gmacri@libero.it> to XML Schema Comments list, Fri, 14 Apr 2000 15:25:15 +0200

I'm a student of Politecnico in Turin. I have written you to ask some information:

[Note re-sent 1 May 2000.]

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 01 May 2000 18:43:26 +0100

When I write an XML document, the URI used in the declaration of a namespace, for example xmlns:book="http://www.somewhere.org/Book, must have some relation with some component defined in the > related schemas?

There doesn't need to be anything at that URI. But if you want to schema-validate elements/attributes from that namespace, you may want one there, or you'll need to define components for those elements in some schema document for that namespace.

The attribute "BLOCK" used in the definition of some schema's component is equivalent to old attribute "EXACT"?

Yes.

Mikael Ståldal <d96-mst@d.kth.se> to XML Schema Comments list, Mon, 17 Apr 2000 12:13:24 +0200 (MET DST)

Section 1.1 in the XML Schema Structures WD says:

The purpose of an XML Schema: Structures schema is to define and describe a class of XML documents by using schema components to constrain and document the meaning, usage and relationships of their constituent parts: datatypes, elements and their content and attributes and their values.

Schemas may also provide for the specification of additional document information, such as default values for attributes and elements. -----

I consider this as two different purposes, and I don't think it's a good idea to mix them together as the schema WD does (DTDs has the same problem). The inclusion of default values in the schema lead to that the output of parsing the same XML document with and without the schema can be different, and I don't like that. I think that validation and supplying default values should be clearly separated processing steps. Likewise, I think that the schema for validation and the defintion for default values should be clearly separated data entites. It should be possible to apply default values without validation, and omitting the validation step should not affect the result for valid input.

My suggestion is to remove default values, and everything else that may cause the output from validating and non-validating parsing to be different, from the XML Schema spec and leave that for some other mechanism (perhaps internal DTD subset for attribute value defaults).

GRMEYER@de.ibm.com to XML Schema Comments list, Mon, 17 Apr 2000 22:55:58 +0200

there are two minor typos in an example in xmlschema-1.html

The base type names should probably be written without '-'

"Curt Arnold" <carnold@houston.rr.com> to XML Schema Comments list, Mon, 17 Apr 2000 23:54:08 -0500

The definition for the simpleType element does not have an explicit reference to the simpleType complexType. I assume this is an error in the schema for schemas and not an indication that their is an implicit typing to an identically named type. However, if I'm wrong, could you point out where this behavior is described.

"Curt Arnold" <carnold@houston.rr.com> to XML Schema Comments list, Mon, 17 Apr 2000 23:54:08 -0500

Restrictions of element content in complex types still looks extremely awkward and under documented. If I've overlooked an concise description of how it should work, please point out the appropriate section. Mimicing the expanded content model up to the point of restriction would be extremely verbose when you are tweaking something fairly deep in a content model.

5. Derivation Issues

5.1 Simplified Derivation By Restriction

The current XML Schema WD requires a complex type derived by restriction to repeat all the declarations it inherited from its base. This becomes tedious and hard to manage as the inheritance hierarchy grows deeper. It would be preferable if only the declarations that are further constrained in the derived type needed to be specified. Its possible that in a deeply nested structure, such repetition might be the only practical way to specify restrictions to the structure without causing ambiguity.

"Curt Arnold" <carnold@houston.rr.com> to XML Schema Comments list, Mon, 17 Apr 2000 23:54:08 -0500

Multiple context-specific defininitions of the attribute element are declared, however they are all identical. It would be confusing to someone looking at a help system when they are presented with the attributeGroup form of the attribute element, the complexType definition of element and don't see any obvious difference.

I just spent the afternoon massaging my schema for XSLT. If you want to check it out, it is at:

http://www.develop.com/dbox/xml/xslt.xsd

I'd love to get feedback, especially from those who have April 7-compliant schema parsers/validators. I still need to go through and tighten up the references to simple types, add xsd:unique, and catch any bugs I am too tired to see today.

"Arnold, Curt" <Curt.Arnold@hyprotech.com> to XML Schema Comments list, Tue, 18 Apr 2000 15:00:55 -0600

... Schema doesn't seem to have the ability to adequately represent the content model of <xsl:template> or <xsl:for-each>. <xsl:template> content should be zero or more <xsl:param> elements followed by template content. <xsl:for-each> content should be zero or more <xsl:sort> elements followed by template content.

Your schema represented these as:

My interpretation of derivedBy='extension' is that any content defined in the derived type appears after the content in the base type. (I looked but couldn't see any definition of special behavior if the base complexType was mixed) So that your definitions would allow template content then <xsl:sort> or <xsl:param> elements. However, since the only mechanism to get mixed content is through a content='mixed' attribute on a <complexType> element and that the only mechanism to build a content model off of a complexType is restriction or extension, there does not seem to be a mechanism for doing what you would really want.

The best approximation you could do with the working draft is to not use derivation and create a mixed model that allows <xsl:sort> or <xsl:param> to appear anywhere in the mixed content.

If you however, had a <mixed> grouping element then you could adequately the content model like:

That led me to look at the content attribute of complexType which appears to only provide information in a very few places and has substantial potential to be inconsistent with other parts of the type declaration. Elimination of the content attribute would seem to eliminate some complexity.

The content attribute can have values of elementOnly, textOnly, mixed and empty.

textOnly can usually be implied by the type attribute referencing a simple type or a <simpleType> child element. The equivalent of content='textOnly' would be nothing more would be type='string'. There doesn't seem to be a case where content='textOnly' adds value.

elementOnly can be implied by a type attribute referencing a complexType or a <complexType> child element.

If we had the <mixed> group tag, then mixed content is just a particular flavor of complex type.

That leaves empty. Either an <empty/> element like in previous drafts or better yet defining an "empty" complex type in the schema for schema that is the default base type if no type is defined and would be the default base type for complexType elements.

I've posted an HTMLHelp file (http://home.houston.rr.com/curta/xslt.chm) based on a simplified version of Don's schema for XSLT (http://home.houston.rr.com/curta/xslt.xsd) on my home page.

"Box, Don" <dbox@develop.com> to XML Schema Comments list, Tue, 18 Apr 2000 15:21:10 -0700

Second, Schema doesn't seem to have the ability to adequately represent the content model of <xsl:template> or <xsl:for-each>. <xsl:template> content should be zero or more <xsl:param> elements followed by template content.

Yeah, I thought about alternative ways to model that. One way would have been to use a named model group (that was my first pass btw). The problem is that for mixed content, you can't use sequence constraints. This is a problem with older technologies as well.

<xsl:for-each> content should be zero or more <xsl:sort> elements followed by template content.

Same problem.

[snip]

I don't know that anyone has the will to add more complexity to the schema language to handle mixed content.

"Arnold, Curt" <Curt.Arnold@hyprotech.com> to XML Schema Comments list, Tue, 18 Apr 2000 16:56:40 -0600

Actually, I thought my suggestions allowed you to appropriately constrain the content plus simplified things by eliminating the content attribute.

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 20 Apr 2000 17:18:32 +0100

Curt Arnold <Curt.Arnold@hyprotech.com> writes:

My interpretation of derivedBy='extension' is that any content defined in the derived type appears after the content in the base type. (I looked but couldn't see any definition of special behavior if the base complexType was mixed) So that your definitions would allow template content then <xsl:sort> or <xsl:param> elements.

Correct.

However, since the only mechanism to get mixed content is through a content='mixed' attribute on a <complexType> element and that the only mechanism to build a content model off of a complexType is restriction or extension, there does not seem to be a mechanism for doing what you would really want.

I'd do it by defining template with a disjunction, and then restricting one or the other branch of the disjunction out of existence for the derived types.

That led me to look at the content attribute of complexType which appears to only provide information in a very few places and has substantial potential to be inconsistent with other parts of the type declaration. Elimination of the content attribute would seem to eliminate some complexity.

The content attribute can have values of elementOnly, textOnly, mixed and empty.

Your discussion below seems to assume that 'content' is an attribute on <element>, when in fact it belongs on <attribute>.

textOnly can usually be implied by the type attribute referencing a simple type or a <simpleType> child element. The equivalent of content='textOnly' would be nothing more would be type='string'. There doesn't seem to be a case where content='textOnly' adds value.

There's one corner case:

is weaker than base='string' (or type='string' on the xs:element), in that it can be restricted by a complex type with any simple type as its base

elementOnly can be implied by a type attribute referencing a complexType or a <complexType> child element.

How can we distinguish mixed from element only in that case?

If we had the <mixed> group tag, then mixed content is just a particular flavor of complex type.

If we had such a group tag, it would re-introduce the pernicious mixed content bug from SGML.

That leaves empty. Either an <empty/> element like in previous drafts or better yet defining an "empty" complex type in the schema for schema that is the default base type if no type is defined and would be the default base type for complexType elements.

I think we're open to re-designs in this area, but this one isn't quite there yet.

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 20 Apr 2000 17:25:06 +0100

Don Box <dbox@develop.com> writes:

Yeah, I thought about alternative ways to model that. One way would have been to use a named model group (that was my first pass btw). The problem is that for mixed content, you can't use sequence constraints. This is a problem with older technologies as well.

Yes you can -- the whole point of making 'mixed' orthogonal to the content model is that e.g.

schema-validates only <haystack> elements with exactly one <thread> and one <needle> daughters, in that order.

Yet another reason to think again about the default <choice> wrapper when you simply say

"Arnold, Curt" <Curt.Arnold@hyprotech.com> to XML Schema Comments list, Tue, 18 Apr 2000 15:00:55 -0600

The param element reference in the named-template type definition should have a minOccur="0" and a maxOccur="unbounded". As written, a template has to have one and only one param.

"Box, Don" <dbox@develop.com> to XML Schema Comments list, Tue, 18 Apr 2000 15:21:10 -0700

My reading of rule 4.3 under the {content type} definition (found under section 4.3.3) implies that there is an implicit <choice minOccurs='0' maxOccurs='unbounded' > particle over the particle children of a content=mixed complex type. I'll defer to Henry on this.

"Arnold, Curt" <Curt.Arnold@hyprotech.com> to XML Schema Comments list, Tue, 18 Apr 2000 16:56:40 -0600

I guess it depends on what the interpretation of "extending" a complex type that ultimately derived from a complex type that has a content of mixed. If extending means that param is magically added into the mixed content of its base type, then the multiplicity would be implied. If extension in this context means appears that content declared in the derived type appears after the base complexType's content has been satisifed then param is in the wrong place with the wrong multiplicity. Possibly the behavior is already explicit in the schema docs. But for me to get my mind around the schema doc, I have to work out from the schemas to schema to the prose and not the other way around.

Noah_Mendelsohn@lotus.com to XML Schema Comments list, Thu, 20 Apr 2000 01:11:45 -0400

Schemas treats mixed differently than DTD's. In schemas, both element-only and mixed take a full content model. The only difference with mixed is that the instance can have character information item children before after and in between the elements validated by the model. So, you have the full power of content models with mixed. Also, mixed does not imply any defaults for min/maxOccurs. This is NOT the DTD model, but it can express every constraint allowed by DTD mixed (and more).

Don Box <dbox@develop.com> to XML Schema Comments list, Wed, 19 Apr 2000 23:23:19 -0700

This is actually a bit confusing, but I think I finally have my head around it (I certainly didn't two days ago).

If one looks at Section 4.3.3 of Part 1, the description of the {content type} deserialization rules discusses the EXPLICIT PARTICLE that is introduced as a parent of most complex type content models. To paraphrase, unless the complexType's content model is a lone all, group, sequence, or choice, the model is interpreted as if a compositor has been introduced. In the case of content='mixed', it is a choice compositor marked minOccurs='0'/maxOccurs='unbounded'.

That stated, I believe (but may be wrong) that the following:

is equivalent to:

This is pretty much the DTD story. If one really wants the "revolutionary structured mixed content model" that acts like elementOnly but allows non-whitespace character data, one would have needed to write this:

where m and n are the values that match your expectations ;-)

Taking this into account, I believe my original schema for XSLT was using content='mixed' correctly, although I now see at least one opportunity to tighten up some constraints.

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 20 Apr 2000 17:29:37 +0100

Curt Arnold <Curt.Arnold@hyprotech.com> writes:

The param element reference in the named-template type definition should have a minOccur="0" and a maxOccur="unbounded". As written, a template has to have one and only one param.\

Don wrote:

My reading of rule 4.3 under the {content type} definition (found under section 4.3.3) implies that there is an implicit <choice minOccurs='0' maxOccurs='unbounded' > particle over the particle children of a content=mixed complex type. I'll defer to Henry on this.

Don is right, but as I've said I think this is sowing enough confusion that the expected benefit is being overwhelmed.

Curt reply:

I guess it depends on what the interpretation of "extending" a complex type that ultimately derived from a complex type that has a content of mixed. If extending means that param is magically added into the mixed content of its base type, then the multiplicity would be implied. If extension in this context means appears that content declared in the derived type appears after the base complexType's content has been satisifed then param is in the wrong place with the wrong multiplicity. Possibly the behavior is already explicit in the schema docs. But for me to get my mind around the schema doc, I have to work out from the schemas to schema to the prose and not the other way around.

I suspect there's some unclarity in this case -- I'll get back to you.

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 20 Apr 2000 17:32:08 +0100

Don Box <dbox@develop.com> writes:

This is actually a bit confusing, but I think I finally have my head around it (I certainly didn't two days ago).

If one looks at Section 4.3.3 of Part 1, the description of the {content type} deserialization rules discusses the EXPLICIT PARTICLE that is introduced as a parent of most complex type content models. To paraphrase, unless the complexType's content model is a lone all, group, sequence, or choice, the model is interpreted as if a compositor has been introduced. In the case of content='mixed', it is a choice compositor marked minOccurs='0'/maxOccurs='unbounded'.

...

The above analysis is entirely correct, as far as I can tell.

Murray Altheim, Review of XML Schema Specification, 11 May 2000

Primer

§2.2 Complex Type Definitions, Element & Attribute Declarations

The third paragraph prior to Table 1 (beginning "The comment element...") describes default values for minOccurs and maxOccurs. This seems counterintuitive. If I leave off maxOccurs it seems that a maximum has not been set, so I'd expect it to be unbounded. The default is however either equal to minOccurs or 1, if minOccurs is absent.

Ray_Gates@manulife.com to XML Schema Comments list, Tue, 18 Apr 2000 16:21:54 -0400

In part 0 (April 7), in section 2.7 Building Content Models, end of para. three, refers to "a single address for those cases where the shipper and biller are co-located."

Surely, this should read "shippee and billee".

petsa@us.ibm.com to XML Schema Comments list, Tue, 18 Apr 2000 10:29:41 -0400 (forwarding note from Gregor Meyer)

A minor comment on the recent XML Schema definitions: xmlschema-2.html defines a type nonPositiveInteger; I have never seen an application where this type would have been useful. The type nonNegativeInteger is often used, though. Is it intended to have an almost complete set of basic types defined by the standard? In my humble opinion there is no need for a standardized type nonPositiveInteger.

"Curt Arnold" <carnold@houston.rr.com> to XML Schema Comments list, Fri, 21 Apr 2000 10:48:02 -0500

I know that there is some reorganization of the physical structure of the schema for schemas intended in the near future and this thought occurred to me while working on the previously mentioned schema compilation project.

Basically, all documents whether they are schemas or not will need to have implied definitions of the builtin datatypes in the same manner as they have an implied definition of xsi:type and xsi:null (especially since a built-in datatype name could be a value for an xsi:type attribute).

Only a minuscule fraction of documents need to have knowledge of the schema definition elements.

This seems to indicate that the definition of the built-in datatypes need to be defined in the xsi namespace (http://www.w3.org/1999/XMLSchema-instance).

Datatypes used in the schema definition elements that are not intended as generally available datatypes (typically commented as utility class not for public use) should be defined in XMLSchema.xsd and would be in the http://www.w3.org/1999/XMLSchema namespace.

When a processor is trying to resolve a type name that is not qualified, it would first look within the current schema and if there was no match, would then attempt to resolve within the schema instance namespace.

So, I'd suggest something like (freehanded definitions, not validated)

xsi.xsd

XMLSchema.xsd

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 21 Apr 2000 17:12:10 +0100

There is already a namespace and a schema for precisely what you have in mind, namely http://www.w3.org/1999/XMLSchema-datatypes

Curt Arnold <carnold@houston.rr.com> to XML Schema Comments list, Fri, 21 Apr 2000 11:32:55 -0500

I had seen that, but I wasn't sure what the intentions were. It seemed like it was defining a parallel namespace. It wasn't clear that the instance and schema definition namespaces would eventually import it and part2.xsd would no longer be included. Definitely seems the right way to go.

Noah_Mendelsohn@lotus.com to XML Schema Comments list, Thu, 27 Apr 2000 00:16:22 -0400

Uh...I'm not sure it's quite that simple. If we are going to encourage coders of schema instance documents to use:

as opposed to:

then we have to be very careful about the semantic implications. Did we finally manage to make these two "integer" types identical in the sense that they would be the same in the augmented infoset? If not, then your suggestion leads users into big problems. I do not typically want my infosets labeled with two subtly different sorts of integers.

Last I heard in New Orleans, we did not have this level of identity. If that is the case, then I think http://www.w3.org/1999/XMLSchema-datatypes is appropriate for use specifically in languages which will not interact with our schemas. We have been quite clear that the typical (though not required) idiom in a schema is:

This suggests to me that the intended instance is the 2nd one above. That said, I have reservations about combining dt: and xsi:; the types can be used in many situations in which xsi: itself would be inappropriate.

Curt Arnold <carnold@houston.rr.com> to XML Schema Comments list, Thu, 27 Apr 2000 00:00:13 -0500

I reviewed the schema for datatypes and there are several things that concern me about it:

My current thinking on this is that:

I believe this arrangement provides a near optimal partition. Built-in types can be accessed either through unqualified names or qualified with the datatypes namespace and generic XML documents do not need to import the symbol space for schema definition.

If not, however I would strongly recommend dropping or avoiding the parallel type hierarchy as currently defined in schema-datatypes.

Curt Arnold <carnold@houston.rr.com> to XML Schema Comments list, Fri, 21 Apr 2000 12:12:23 -0500

Namespace prefix definitions (xmlns:prefix="uri" attributes) are not accessible from XSLT (and probably from anything else that tries to hide the details of namespacing from you) which means that it is not possible to resolve qualifed name references to types, for example, in those environments. I'd suggest adding an explicit schemaPrefix attribute to the import and targetPrefix attribute to the schema element. At least, this information could be used as decoration in the documentation. I am able to work around this using equivalent attributes from another namespace, but it seems like a general problem.

Curt Arnold <carnold@houston.rr.com> to XML Schema Comments list, Fri, 21 Apr 2000 12:12:23 -0500

Of course, any implementation has to have some limit on the depth of nested includes.

Curt Arnold <carnold@houston.rr.com> to XML Schema Comments list, Fri, 21 Apr 2000 12:12:23 -0500

A complicated issue is nested imports. It should be moderately common for multiple imports to in turn import some common namespace but possibly from different resources. Trying to resolve the potential conflicts seemed untenable.

How I've currently addressed it in my preprocessor is that only imports that in the schema being compiled add information to the validation package. If an import appears in an include or import and its namespace didn't have an import in the schema being compiled, an informative message is issued (but which might result in some unsatisfied references).

"Curt Arnold" <carnold@houston.rr.com> to XML Schema Comments list (and xml-dev) on Thu, 11 May 2000 01:19:19 -0500

Section 6.3.2: Point 4

There would also be the need for some sort of statement when inconsistent schemaLocations appear for the same namespace. I would assume that the first would take precedence.

Jim Trezzo <jtrezzo@us.oracle.com> to XML Schema Comments list on Fri, 12 May 2000 16:03:28 -0700

3. SchemaLocation problems

The XMLSchema spec seems to allow one to create XML schemas which can contain references to element declarations and type definitions from other namespaces, without having to provide the schemas that contains those definitions. In effect, each instance document can then suggest the location of the other schemas, or the schema processor must have some other way of finding them.

This presents a problem when we are trying to validate multiple documents against a schema (or create a repository for documents conforming to a schema), since each document might suggest changing the type structure for the elements in this schema.

The upshot of this is that implementations are required to provide a way of locating schemas outside of the <import> system if they want to avoid using the <schemaLocation> in the instance documents (which is horrible).

We would like to require specification of the schemaLocation attribute in an <import> element in the schema, so that we don't have to provide an alternative schema location mechanism for schemas that come to us without <import schemaLocation=>. The spec should still allow the <import> to be ignored like <schemaLocation>, for systems that will find schemas by other means.

Murray Altheim, Review of XML Schema Specification, 11 May 2000

Part 1 : Structures

§6.3.2 How schema definitions are located on the Web

Under Schema Representation Constraint: Schema Document Location Strategy, I'm simply amazed at the lack of constraint here. From my reading of this section, almost anything goes, and I don't understand how a conformance definition could include this normatively.

"Dario de Judicibus" <ddj@mclink.it> to XML Schema Comments list, Tue, 25 Apr 2000 23:12:02 +0200

The proposals first. The first one is related to lists of strings (simple types). Standards state that no list of string can be defined if some string contain spaces, because list are space separators. In my personal opinion this is a weakness of the standard, especially if you consider that we are speaking of Unicode strings, where the concept (and code point) of space may differ from language to language. What about adding a new facet for simple types which allow to specify the list separator? Default would be blank space 0x20. So we might have

Curt Arnold <carnold@houston.rr.com> to XML Schema Comments list, Wed, 26 Apr 2000 07:56:59 -0500

I am a long time observer of the W3C XML Schema spec and not a member of the W3C or the working group, so what I'm going to say is not official W3C, but things covered in previous posts.

List separators: The working group explicit decided to allow only the space separated lists at this time. Even getting that took a whole lot of work. Some other W3C work (scalable vector graphics) for instance does use other delimiters and if this is going to be changed it will be done to accomodate the uses in other W3C efforts.

"Dario de Judicibus" <ddj@mclink.it> to XML Schema Comments list, Tue, 25 Apr 2000 23:12:02 +0200

The comments now. The first is related to <anyAttribute>. Differently from <any>, it does not look useful to allow any attribute of a specific schema to be used in a specific element of another schema. It makes more sense to allow any attribute belonging to an attribute group of a specific schema to be used in another element. For example

"Dario de Judicibus" <ddj@mclink.it> to XML Schema Comments list, Tue, 25 Apr 2000 23:12:02 +0200

Final comment: there is no way to combine types. For example, if I have

I have no way to define

by combining xsd:decimal and units. That might be very useful. We might use a variant of pattern for that:

Curt Arnold <carnold@houston.rr.com> to XML Schema Comments list, Wed, 26 Apr 2000 07:56:59 -0500

The schema group stated that aggregate types were outside the scope of the initial version. Derivation by list was a hard fought exception to that principle.

If you are interested in discussions of dimensional units in XML, I can send you URL's to quite a few discussions.

"Martin Bryan" <mtbryan@sgml.u-net.com> to XML Schema Comments list on Sun, 14 May 2000 08:01:08 +0100

The one area I still expect we are going to have problems in using datatype for electronic commerce is measurements. For example, how can I check that 100cm and 1m are exactly equivalent, but 1yd is not. But again I do not expect you to have addressed these problems at this state. (Schema2 will be along within a few years!)

Ray Waldin <rwaldin@pacbell.net> to XML Schema Comments list, Wed, 26 Apr 2000 03:45:10 -0700 (as corrected 26 Apr 2000 03:51:53 -0700).

I have some questions and a comment concerning SimpleTypes derived "by restriction". To illustrate:

This seems perfectly acceptible as secondType is derived from firstType "by restricting its value space", by specifying "more restrictive" values for some facets. Here's a case that's not so obvious, using "less restrictive" values:

My questions:

Is this disallowed or just pointless? In other words, should a schema processor regard this type derivation as an error, or simply produce a thirdType which is no more restrictive than firstType?

What does "more restrictive" mean for the period and duration facets? Can period and duration be re-specified in any meaningful way or is re-specifying either of these values disallowed?

If a derived type re-specifies the pattern facet (as in the case of NCName and Name), are schema processors expected to: A) ensure that a derived type specifies a "more restrictive" pattern than its base type, or B) check all patterns in a type's derivation hierarchy when validating an instance of that type?

My comment:

The datatypes spec should elaborate on the expected behavior of schema processors when encountering derived types which re-specify values for each facet.

Curt Arnold <carnold@houston.rr.com> to XML Schema Comments list, Wed, 26 Apr 2000 07:33:29 -0500

My personal preference would be that "looser" facets would be tolerated, though an ideal schema profiler might tell that you are wasting cycles or optimize the evaluation. I don't think that suboptimality is a good reason to reject a document and the complexity involved in determining the active constraint set is not justified in my opinion. While figuring out the looser constraint is fairly obvious for min/max, what if were trying to better if one pattern is looser than another (and both could be active).

As a pattern, I know of no programming language that would fail to compile a conditional like:

It would be a conceptual error for the duration facet to be specified with two distinct values in a type hierarchy. You shouldn't be able to derive from day and stretch the day to 25 hours. The resulting type (25 hour periods starting at a particular midnight) doesn't fit into the value space of 24 hour periods starting at midnight. I could see making a duplicate specification of duration in a hierarchy an error, I would not try to determine if the values of the duration were identical (say if one had said P1D and another PT3600s)

Multiple period facets can make sense in a hierarchy make sense. You could create a derived type from time with a period of 48 hours that represented a particular time of day every other day. I can't see anything a schema validation can do with the period facet. It seems like a piece of information only the application uses (if it wants) to determine the meaning of the type.

Richard Tobin <richard@cogsci.ed.ac.uk> to XML Schema Comments list, Wed, 26 Apr 2000 15:12:10 +0100

The use of named model groups allows content models that are not regular expressions. For example:

Useful though this would be, it is probably not intended.

dejudicibus@it.ibm.com to XML Schema Comments list, Thu, 27 Apr 2000 12:41:19 +0200

Maybe this is trivial for those of you joined this group long time ago, but I cannot find info about:

in one of the old draft of XML Schema, it was possible to define entities too. For example

Why that is no more possible? And what can I use to define entities, now?

James Tauber <JTauber@bowstreet.com> to XML Schema Comments list, Fri, 28 Apr 2000 02:42:09 -0400

Why are {min occurs} and {max occurs} optional in Attribute Declaration?

The meaning of "absent" for these properties doesn't seem to be defined in 3.2 and I can't think of what it would be.

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 28 Apr 2000 08:54:07 +0100

Because they don't make sense on top-level declarations. It's entirely parallel to element declarations, just less obvious because we make Particle explicit between content model and element declaration, but leave what my parser calls AttributeUse implicit between type def and attr decl.

James Tauber <JTauber@bowstreet.com> to XML Schema Comments list, Fri, 28 Apr 2000 03:55:45 -0400

Because they don't make sense on top-level declarations.

So, could a sentence be added to this effect?

James Tauber <JTauber@bowstreet.com> to XML Schema Comments list, Fri, 28 Apr 2000 04:16:55 -0400

Why is the {name} of the Ur-Type (as a Complex Type) in 3.4 shown as "Not specified"? How is this different from "absent"?

I assume that anonymous complex types in general have "absent" as their {name} or is this not true?

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 28 Apr 2000 09:22:11 +0100

Why is the {name} of the Ur-Type (as a Complex Type) in 3.4 shown as "Not specified"? How is this different from "absent"?

No particular reason - should probably be 'absent'.

I assume that anonymous complex types in general have "absent" as their {name} or is this not true?

Correct.

James Tauber <JTauber@bowstreet.com> to XML Schema Comments list, Fri, 28 Apr 2000 04:18:37 -0400

Why does "absent" in the "Complex Type Definition of the Ur-Type" tableau (and possibly elsewhere) point to the definition for "null" in the glossary?

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 28 Apr 2000 10:33:33 +0100

That's a bug, arising from a late decision to change from 'null' to 'absent'.

James Tauber <JTauber@bowstreet.com> to XML Schema Comments list, Fri, 28 Apr 2000 04:20:18 -0400

I thought there used to be a Simple Type Definition of the Ur-Type? Should there be one in 3.13 parallel to the one for Complex Types in 3.4? Or am I missing something?

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 28 Apr 2000 10:36:39 +0100

This is a tricky issue. The ur-type is neither simple nor complex. What's given in 3.4 is what it looks like as the base of a complex type definition. There's no way to show what it looks like as the base of a simple type definition, or rather, that would simply be a simple type definition with no values for any of the properties, which would not be terribly helpful.

I agree the prose explaining all this is less than satisfactory.

I get it totally now that you have explained to me, which seems to suggest that an additional sentence or two in the prose could do a great deal.

James Tauber <JTauber@bowstreet.com> to XML Schema Comments list, Fri, 28 Apr 2000 07:28:18 -0400

In the XML Representation Summary for anyAttribute in 4.3.3, anyAttribute is not shown as taking a processContents attribute. The schema for schemas and the DTD for schemas does not allow it, either.

However, 1.1 of the {attribute wildcard} property correspondence mentions it.

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 28 Apr 2000 14:29:32 +0100

It should allow it, you're right.

James Tauber <JTauber@bowstreet.com> to XML Schema Comments list, Fri, 28 Apr 2000 09:16:47 -0400

In 4.3.7, in the representation summary for the "any" element information item, it indicates that the attribute "namespace" takes either:

However, in the "otherwise" section of the correspondences to the Wildcard Schema Component, it refers to ##local as being a substring in the list (and this is in fact the only mention of ##local)

Should the representation summary really read:

?

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 28 Apr 2000 14:33:10 +0100

Your analysis is correct. But I think you typoed above -- the corrected summary should read

James Tauber <JTauber@bowstreet.com> to XML Schema Comments list, Fri, 28 Apr 2000 15:52:55 -0400

In 3.2, the {value constraint} property of Attribute Declaration components seems to allow a (value, absent) pair. This is supported by the property correspondences for "attribute" element information items (4.3.1) directly under "schema" where {value constraint}'s representation is:

If there is a value attribute, then a pair consisting of the lexical value of that attribute and absent, otherwise absent

What is the meaning of a {value constraint} that is a (value, absent) pair?

In this particular case, it seems the value of the "use" attribute is ignored, but doesn't it default to "optional"?

James Tauber <JTauber@bowstreet.com> to XML Schema Comments list, Fri, 28 Apr 2000 16:10:56 -0400

In the second case in 4.3.1, a representation is given for when the attribute element information item is not a direct child of schema (that's the first case). However, in the representation of {target namespace} it refers to the targetNamespace attribute of the parent schema element.

Should this say "ancestor"?

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 28 Apr 2000 23:04:12 +0100

"Joseph M. Reagle Jr." <reagle@w3.org> writes:

I used to both schema and DTD validate, but I didn't realize these things had moved. I'll try using these URLs and see if it still works. However, this policy of locating the schema and DTD at the namespace is pretty confusing. I appreciate you don't want to change the namespace every time you issue a new draft and I hope you would try every time you made a substantive change, because now the result is that even if I write my XML instance that (today) validates under [1,2] next time you put out a new draft it won't! Before, not updating your namespace violated a philosphical point (but the actual dtd and schema were in a more specific (month) date space). Now you are violating a more practical point, if I have an example that works now based on something in date space it won't in the future. (I think, right?)

[1] http://www.w3.org/1999/XMLSchema.dtd

[2] http://www.w3.org/1999/XMLSchema.xsd

Well, it's a difficult point. I'd say we don't have a namespace yet, we're just working towards having one, and using the same name so people will get used to it as the XML Schema namespace.

I appreciate your point about things going stale -- if we ever make a backwards incompatible change, we'll put the old schema and dtd somewhere in date space and you can use them for your stale documents.

We're in new territory here (never before has there been a definitive and operational anything at a namespace URI before), Dan and I have been making policy by the seat of our pants, by all means lets keep discussing this, but move the archiving to the public comments list (see addresses above).

Dan Connolly <connolly@w3.org> to XML Schema Comments list, Fri, 28 Apr 2000 17:48:22 -0500

"Henry S. Thompson" wrote:

Well, it's a difficult point. I'd say we don't have a namespace yet, we're just working towards having one, and using the same name so people will get used to it as the XML Schema namespace.

Really? That seems like an odd way of looking at things, to me. It's quite clear to me that we have a namespace; the definition is what you get back from http://www.w3.org/1999/XMLSchema.

And if we change the definition, it's sort of antisocial to re-use the old address, as Joseph has observed. Though this is work-in-progress stuff, and we don't really plan to support drafts once they've been superceded, we might as well avoid the sort of problems Reagle is having when it's easy to do.

I appreciate your point about things going stale -- if we ever make a backwards incompatible change, we'll put the old schema and dtd somewhere in date space and you can use them for your stale documents.

Again, that seems backwards; if we make backwards-incompatible changes, the thing to do is to leave the old one alone and use a new identifier for the new definition. It's not really fair to expect folks to change pointers in old documents.

If we decide to break their old documents, i.e. to not support them, that's one thing. But the way to support them, if we're going to go to any trouble at all, is to just leave the old definition in place if we make a new, incompatible one.

Joseph M. Reagle Jr. <reagle@w3.org> to XML Schema Comments list, Fri, 28 Apr 2000 18:15:46 -0400

At 23:04 2000-04-28 +0100, Henry S. Thompson wrote: I appreciate your point about things going stale -- if we ever make a backwards incompatible change, we'll put the old schema and dtd somewhere in date space and you can use them for your stale documents.

But I can't touch my WD in the TR space, which used to work and won't when you make these changes.

Noah_Mendelsohn@lotus.com to XML Schema Comments list, Fri, 28 Apr 2000 19:12:23 -0400

Dan, I think you're presuming answers to a versioning architecture for XML and namespaces. I believe that to be a known hard problem which, in spite of my suggestions to the contrary [1], the XML activity has so far declined to formally consider (I believe it was discussed informally at a CG meeting, perhaps in Montreal last year.)

Everything you propose, i.e. immutable namespaces, makes sense in isolation. The problem I see is that none of the other necessary XML machinery has been developed. Let's assume that some particular vocabulary undergoes within a year 20 minor modifications, mostly bug fixes,introducing little incompatibilities that are not of concern to the vast majority of users. So, over the course of the year, 100,000 documents are written to this vocabulary, 5,000 in each of the 20 namespaces. Question: how do I build and maintain 30 XSL stylesheets that do the right thing with these documents? For the sake of discussion, none of the stylesheets happen to make use of any of the features that were affected by the 20 bug fixes. Were it not for the decision to make namespaces immutable, a single set of 30 stylesheets would suffice, and none of the 30 would have required change through the year. Presuming immutable namespaces, which do indeed have many desirable architectural properties, I either need 600 stylesheets (30 useful sheets x 20 namespaces used in the instances), or some rather messy disjunctions in each of my XPaths.

I do not propose that we go into an extensive discussion of versioning here. I merely wish to agree with Henry that the answers are far from clear, and in that sense we are feeling our way. I think we are far from having worked out the practical ramifications of any particular fixed design for versioning, including any that might be based on immutable namespaces. It is my opinion that almost anything practical we do for robust versioning of XML vocabularies will require some serious engineering in one or another of our existing XML specifications (e.g. XPath, if you believe the analysis above). Pending such developments, I think we in the schemas group will have to make decisions that are somewhat ad hoc at times, perhaps republishing minor fixes as changes to the same namespace, with some means of deploying new ones for major changes. In short, I think we are about to get bitten by an overall lack of investment in figuring out how to do namespace and vocabulary versioning in a robust manner. Maybe I am just being too pessimistic.

[1] http://lists.w3.org/Archives/Member/w3c-xml-plenary/1999Oct/0019.html (My apologies to those on the schema comments list who cannot access this member-only e-mail archive. The note basically suggests that versioning is an important problem that will rear its head soon, and points out some of the issues to be considered.)

Dan Connolly <connolly@w3.org> to XML Schema Comments list, Fri, 28 Apr 2000 20:44:40 -0500

Noah_Mendelsohn@lotus.com wrote:

Dan, I think you're presuming answers to a versioning architecture for XML and namespaces.

I'm observing an answer. Not the only answer, but one that is known to work (i.e. to avoid the problem Joseph ran into).

I believe that to be a known hard problem which, in spite of my suggestions to the contrary [1], the XML activity has so far declined to formally consider (I believe it was discussed informally at a CG meeting, perhaps in Montreal last year.)

Declined to consider versioning? Hardly! Evolution of specs is one of W3C's core values. cf "Web Architecture: Extensible Languages" http://www.w3.org/TR/1998/NOTE-webarch-extlang-19980210

I guess it could depend on your definition of 'formal'. But... I look hard at forward/backward compatibility of all the specs, and I'm not the only one. We insisted on some last-minute changes to XSLT (a way to make xslt:message act as a halt-and-catch-fire instruction) for exactly this reason.

Everything you propose, i.e. immutable namespaces, makes sense in isolation. The problem I see is that none of the other necessary XML machinery has been developed. Let's assume that some particular vocabulary undergoes within a year 20 minor modifications, mostly bug fixes,introducing little incompatibilities that are not of concern to the vast majority of users. So, over the course of the year, 100,000 documents are written to this vocabulary, 5,000 in each of the 20 namespaces. Question: how do I build and maintain 30 XSL stylesheets that do the right thing with these documents?

I think you've answered your own question. You just do. It's hard and awkward, but clearly it's possible.

The answer I'm talking about meets some requirements (namely, that you can write a document and be assured that it will be interpreted consistently henceforth) but doesn't meet others, i.e. easy maintenance of stylesheets.

For the sake of discussion, none of the stylesheets happen to make use of any of the features that were affected by the 20 bug fixes. Were it not for the decision to make namespaces immutable, a single set of 30 stylesheets would suffice, and none of the 30 would have required change through the year. Presuming immutable namespaces, which do indeed have many desirable architectural properties, I either need 600 stylesheets (30 useful sheets x 20 namespaces used in the instances), or some rather messy disjunctions in each of my XPaths.

Right.

I do not propose that we go into an extensive discussion of versioning here. I merely wish to agree with Henry that the answers are far from clear, and in that sense we are feeling our way.

I agree that the whole general problem of language evolution is messy. But I maintain that there's one mechanism, immutable resources, that's known to avoid the problem Joseph ran into.

I think we are far from having worked out the practical ramifications of any particular fixed design for versioning, including any that might be based on immutable namespaces. It is my opinion that almost anything practical we do for robust versioning of XML vocabularies will require some serious engineering in one or another of our existing XML specifications (e.g. XPath, if you believe the analysis above). Pending such developments, I think we in the schemas group will have to make decisions that are somewhat ad hoc at times, perhaps republishing minor fixes as changes to the same namespace, with some means of deploying new ones for major changes.

Sure... I just disagree that Henry's approach of "we'll put the old one someplace that you can find it" is very useful.

In short, I think we are about to get bitten by an overall lack of investment in figuring out how to do namespace and vocabulary versioning in a robust manner. Maybe I am just being too pessimistic.

If we had to design all parts of the Web before we deployed anything, where would we be? I guess I have a little more faith that economical solutions will present themselves in a timely fashion ;-)

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 29 Apr 2000 10:13:24 +0100

I'll make three observations:

1) In the nicest possible way, I'm not sure what we owe to Joseph on this one. We have not published this namespace yet, in the sense of asserting publicly in a process-blessed way that http://www.w3.org/1999/XMLSchema is the namespace URI for a namespace whose semantics are defined in some officially approved REC.

2) The thrust of Dan's remarks are at odds with my memory of the discussions surrounding the decision to enforce http://www.w3.org/1999/XSL/Transform as the namespace URI for XSLT, which strongly suggested a philosophical stance about persistent identity clearly at odds with the practical reality of changing details. In particular the decision to not add a version number to that NS URI was taken after considerable thought.

I'm afraid this takes us back to my concern about too-tight connection between namespace URI and presumed resource (= XML Schema in this case) location.

3) There's certainly precedent for 'stable' resources evolving: the XML Spec DTD still lives at http://www.w3.org/XML/1998/06/ although it's currently in its 21st edition.

Dan Connolly <connolly@w3.org> to XML Schema Comments list, Sat, 29 Apr 2000 09:27:15 -0500

"Henry S. Thompson" wrote:

... 1) In the nicest possible way, I'm not sure what we owe to Joseph on this one. We have not published this namespace yet, in the sense of asserting publicly in a process-blessed way that http://www.w3.org/1999/XMLSchema is the namespace URI for a namespace whose semantics are defined in some officially approved REC.

While it's true that we're not 100% bound to support old drafts, I hope that the spec will gradually stabilize; i.e. that we'll gradually make more of an attempt to avoid problems like the ones Joseph ran into.

2) The thrust of Dan's remarks are at odds with my memory of the discussions surrounding the decision to enforce http://www.w3.org/1999/XSL/Transform as the namespace URI for XSLT, which strongly suggested a philosophical stance about persistent identity clearly at odds with the practical reality of changing details. In particular the decision to not add a version number to that NS URI was taken after considerable thought.

I'm not sure what you mean by "enforce", but perhaps that's no matter...

My remarks aren't at odds with the way the XSLT namespace works; they just don't apply. The XSL WG decided not to promise that the XSLT namespace won't change. I think they made some promise about never changing the namespace is such a way that would change the semantics of a stylesheet that conforms to XSLT 1.0, but they left open the possibility of backward-compatible changes to the namespace (where "backwards-compatible change" is not formally specified).

I have not said that every namespace resource must be immutable. I have just said that using immutable resources as namespaces has some desireable characteristics, including avoiding the "that schema just changed out from under me" problem that Joseph ran into.

I'm afraid this takes us back to my concern about too-tight connection between namespace URI and presumed resource (= XML Schema in this case) location.

In any particular way? Or just general unease?

3) There's certainly precedent for 'stable' resources evolving: the XML Spec DTD still lives at http://www.w3.org/XML/1998/06/ although it's currently in its 21st edition.

I'm not sure what you mean by 'stable'. That resource isn't "stable published" in the Ted Nelson sense; it changes whenever Eve feels like it. Contrast that with http://www.w3.org/TR/1998/REC-xml-19980210 or http://www.ietf.org/rfc/rfc0822.txt which are guaranteed by their publishers not to change, or mid:f5b66t16zij.fsf@cogsci.ed.ac.uk which is guaranteed by the definition of the URI scheme not to change.

Joseph M. Reagle Jr. <reagle@w3.org> to XML Schema Comments list, Mon, 01 May 2000 15:39:35 -0400

At 09:27 2000-04-29 -0500, Dan Connolly wrote: BTW: Has there ever been any consideration in schema (I thought I saw this but don't see it presently) to include a location attribute in the schema element type? If a namespace need not be dereferencable (like PUBLIC) then wouldn't it make sense to include a SYSTEM as well?

Found it, I knew that I saw it before: 2.6.3 xsi:schemaLocation, xsi:noNamespaceSchemaLocation The xsi:schemaLocation and xsi:noNamespaceSchemaLocation attributes http://www.w3.org/TR/xmlschema-1/#xsi:schemaLocation

So including these attributes in the schema for schema example in the spec would be helpful.

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 01 May 2000 21:42:20 +0100

I'm confused by the above extracts, perhaps the context would have clarified things.

SYSTEM and PUBLIC are part of the mechanisms by which an XML instance points to external entities, in particular to (the external subset of) DTDs.

The analogous aspects of XML instances for schemas are xsi:schemaLocation and xmlns, where xsi is declared as http://www.w3.org/1999/XMLSchema-instance.

You can put a schemaLocation attribute from that namespace on any element in any document without it needing a declaration.

There's a lengthy discussion of all this in section 3 of chapter 6 of the spec. [1].

I'm slightly at a loss to know exactly what you are asking for -- are you suggesting that the schema for schemas should be modified to include a namespace declaration for http://www.w3.org/1999/XMLSchema-instance and a schemaLocation attribute from that namespace? We could do that, but since the schema which applies to the schema for schemas, which is of course itself (:-), actually does live at its namespace URI, there didn't seem any point.

I'm also perplexed by the analogy with SYSTEM and PUBLIC, in that in vanilla XML 1.0, you don't find those inside DTD documents at all.

But maybe that's not what you meant.

Joseph M. Reagle Jr. <reagle@w3.org> to XML Schema Comments list, Tue, 02 May 2000 18:38:42 -0400

I'm not surprised as I wasn't being very cogent. <smile> I was thinking something like the following would've mitigated my confusion (particularly as represented in the spec so I would know where to find things).

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 03 May 2000 09:36:37 +0100

Right, we could have done that, and anticipating that there may be processors which chose never to attempt dereferencing namespace URIs perhaps we should.

"Joseph M. Reagle Jr." <reagle@w3.org> to XML Schema Comments list on Wed, 10 May 2000 12:48:14 -0400

2.5 Names and Symbol Spaces

The fact that you are using the same namespace "http://www.w3.org/1999/XMLSchema" across different specifications with substantively different syntaxes may cause problems for applications that expect the definition of a dated name space to be stable. See http://lists.w3.org/Archives/Public/xmlschema-dev/2000Apr/0026.html for more discussion on this topic:

Noah_Mendelsohn@lotus.com to XML Schema Comments list, Fri, 28 Apr 2000 19:24:14 -0400

I would like to raise a new issue for consideration in last call of XML schema. I think this request is based on new information, and I request that it be placed on our list for consideration.

As James Tauber has noted, we do not have an explicit name for the urType. The new information is that, during the design of the latest SOAP specification [1], we realized that even if the schema language itself can get by without a string name for the type, other systems have real need for such a name.

In a nutshell, SOAP has its own mechanisms for declaring array-like structures beyond those currently offered by schemas themselves. So, you will see SOAP elements labeled with attributes like:

which refers to an array encoded as three XML elements each of which is conformant with xsd:integer. Or:

I happen not to be thrilled with that particular syntax, because I would prefer explicit markup and not to have QNames buried within a string, but neither of those is the issue here. The requirement is for some means of saying things like:

to indicate an array of three elements each of which must be a (subtype of) our urType. As with our schema design, the intention is to allow both simple types and complex types in the instance, so it is truly is our notion of urType.

I believe that SOAP is not the only system that will emerge with such a requirement.

If we as a workgroup decide not to provide such a name for the type, then it is likely that SOAP will wind up defining something like SOAP-ENC:urType with an indication that it refers to the urType of XML schemas (indeed, that was supposed to make it into the SOAP 1.1 specification and didn't quite because the problem was noticed too late.) I think everyone involved believes that would be undesirable. So, the request is for an officially-blessed name for the urType. (Note: this is not a request to try to split into separate urTypes for simple and complex... just a name for what we have got.)

By the way, I think most ordinary mortals will find the term urType to be unduly obscure. Perhaps something like "xsd:base"? I'm sure we could amuse ourselves with a little name-the-urType contest. Thank you very much.

[1] http://www.ibm.com/software/developer/library/soap/soapv11.html

On this issue of urType, I think I would prefer an explicit declaration of an urType and the derivation of all types in a domain from it.

My entry for the name the ur contest is root or rootType.

"Vun Kannon, David" <dvunkannon@kpmg.com> to XML Schema Comments list, Mon, 1 May 2000 16:28:00 -0400

I am considering, as the subject line says, using appinfo annotations to store integrity constraints. Consider a document as the transfer syntax for a database predicate. An integrity constraint might be "no worker earns more than their supervisor" or "pay_rate > 0". These integrity constraints could be expressed as CHECK constraints in SQL, for instance.

I was considering trying to achieve the same effect with XSL-T templates in appinfo elements. Unfortunately, it appears that even in the April 7 draft, annotation and appinfo are poorly documented. Annotation is used but not defined in either the schema for schemas or DTD, and appinfo (and documentation) similarly. What is the content model ()+ supposed to mean, in sec 4.3.10?

Your comments appreciated on the appropriateness of the idea, and my understanding of appinfo.

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 01 May 2000 21:46:13 +0100

"Vun Kannon, David" <dvunkannon@kpmg.com> writes:

I am considering, as the subject line says, using appinfo annotations to store integrity constraints. Consider a document as the transfer syntax for a database predicate. An integrity constraint might be "no worker earns more than their supervisor" or "pay_rate > 0". These integrity constraints could be expressed as CHECK constraints in SQL, for instance.

That's exactly the sort of thing appinfo is designed for. Sorry the documentation is less complete in this area than it should be.

As the schema for schemas reveals, the content model for appinfo is constrained only in so far as it may not contain elements from the XML Schema namespace itself -- anything else, in any combination, is fine.

So declare a namespace at the top of your schema, and put whatever you like from that namespace inside appinfo. If you give your schema validator a schema for that namespace as well as the schema for schemas, the contents of appinfo from that namespace will get schema-validated as well.

"Vun Kannon, David" <dvunkannon@kpmg.com> to XML Schema Comments list, Wed, 3 May 2000 11:53:02 -0400

Got it.

"Vun Kannon, David" <dvunkannon@kpmg.com> to XML Schema Comments list, Wed, 3 May 2000 11:53:02 -0400

I'm also thinking about appinfo for what I've taken to calling my "#IMPLIED resolution strategy". I want my schema to state explicitly what to do if a particular attribute is absent from an instance of an element for which that attribute is declared. For instance, the strategy that most of my attributes follow is:

which means that the attribute must exist somewhere among the containing elements. Choosing the nearest value gives this useful behavior that the attribute can be given a default, then the default overridden for any subtree.

Is this idea of "absent attribute resolution strategy" useful enough to all schemas that it should be part of XSchema itself, as opposed to hiding it under the appinfo bushel?

Rick JELLIFFE <ricko@geotempo.com> to XML Schema Comments list, Thu, 04 May 2000 01:32:15 +0800

From: Vun Kannon, David (dvunkannon@kpmg.com) Is this idea of "absent attribute resolution strategy" useful enough to all schemas that it should be part of XSchema itself, as opposed to hiding it under the appinfo bushel?

Being able to declare that an attribute should have a value inherited from its parents (if that is the idea) was considered but not taken up. It would have been useful for xml:lang too. The line has to be drawn somewhere, of course (in the absense of some kind of extensible implied-attribute-value resolution framework).

Curt Arnold <carnold@houston.rr.com> to XML Schema Comments list, Mon, 1 May 2000 23:48:22 -0500

hst wrote:

As the schema for schemas reveals, the content model for appinfo is constrained only in so far as it may not contain elements from the XML Schema namespace itself -- anything else, in any combination, is fine.

I was just thinking about this, the has-facet and has-property elements in part2.xsd should be outside of the XMLSchema namespace.

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 02 May 2000 09:10:34 +0100

"Falk, Alexander" <falk@icon.at> writes:

Interesting question... I've looked at both the primer and the (normative) schema for schemas and DTD for schemas. The first seems to indicate that 'xsd:list' should be used, but the normative meta-schema and DTD clearly say that it should be 'list' all by itself.

Maybe someone else can shed some authoritative light on this: if the schema-namespace is defined with prefix xsd, and we have the following simpleType definition

should the derivedBy be 'list' (like the meta-schema and DTD say), or should it be 'xsd:list' (like the primer says)?

My opinion is that the primer is the mistaken one here. The 'derivedBy' attribute has an enumerated type, with values 'extension', 'list' and 'restriction'. It's not a reference, which would have type QName.

Dan Vint <DVint@lexica.net> to XML Schema Comments list, Tue, 2 May 2000 07:56:33 -0700

I've been trying to use the schema as presented in Appendix A of Part 2 and have come across this piece of data that seems to be out of place or at least missing some more markup:

Between the two complexType definitions is this annotation and simpleType that is broken.

Dan Vint <DVint@lexica.net> to XML Schema Comments list, Tue, 2 May 2000 08:00:53 -0700

In the Appendix A (of part 2) the definition of this complexType has the attribute base as an empty tag, but the close tag appears later.

Dan Vint <DVint@lexica.net> to XML Schema Comments list, Tue, 2 May 2000 08:35:46 -0700

1) On the webpage http://www.w3.org/TR/xmlschema-1/ at the top are links to:

"with separate provision of the schema and DTD for schemas described herein. "

The thought was these would be the same as the Appendix versions of the schema and DTD, I beleive they are at least different versions. The relationship between these links and the later appendix information should be clarified and a clearer statement about these top level links should be made as well.

2) In the Appendix for part 1 and part 2, the SCCS ID variables show different names for the actual files than what appear to be the specified INCLUDE and DOCTYPE values for these files.

"Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com> to XML Schema Comments list, Tue, 2 May 2000 15:43:11 -0400

I suppose my greatest concern is that the capabilities represented in the Schema work are not further extendible without also extending the Schema syntax. That's a steep hill for proposed new extensions to climb, and will likely act as a squelch on such extensions. As one who sees shortcomings in what is supported in the current Schema work, I find the closed Schema syntax disturbing.

...

Amid the complexity of the Schema specification is some much wished for capability, and I've been among those making wishes, as the DTD capability provides little of what is needed for Business Information Exchange. But as much as I want such capability, I fear that Schema is all we'll get, it won't be enough, and we'll have to pass it by for something better. That would be disheartening.

A design more in keeping with my desires for extensibility would define a syntax by which active service packages could be associated with XML elements. Edit constraints might be one such service, and one which might (and should) be pre-defined for use. The addition of new services would not require a change to the XML Schema syntax, it would simply require the definition of the new service and access to the process(es) supporting the extended service.

If a service approach were to be considered, some thought should be given to other services that might be desired (such as an array processing service), such that service syntactic support needs are adequately addressed in the underlying Schema syntax, even if the considered services are not fully defined and implemented.

"Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com> to XML Schema Comments list, Tue, 2 May 2000 15:43:11 -0400

Perhaps the emphasis on `syntax' that underlies the XML DTD specification has too strongly influenced the efforts of people who recognized the limitations of DTD's. In my opinion, more attention needs to be paid to the semantics of information, and less to the syntax of information. There is little support for access to semantic information in the Schema work, where much work is needed.

The ebXML work with which I am a participant envisions repositories of semantic information. Certain of the semantic information in such repositories, such as value constraints, can be represented in the Schema syntax. But other important semantic attributes, (e.g.,a pointer to a repository of semantic information about an XML element), have no specific representation in the Schema.

"Miller, Robert (GXS)" <Robert.Miller@gxs.ge.com> to XML Schema Comments list, Tue, 2 May 2000 15:43:11 -0400

Just today, I received an Email from someone who had seen my earlier Email to the Schema Work Group pointing out the need to support arrays of information. Spreadsheets, a simple array construct, are not provided a common representation in the XML Schema work.

...

If a service approach were to be considered (cf. issue XML Schema considered inadequately extensible), some thought should be given to other services that might be desired (such as an array processing service), such that service syntactic support needs are adequately addressed in the underlying Schema syntax, even if the considered services are not fully defined and implemented.

1. Datatypes Issue MPEG-7 requires both arrays and matrices. We would prefer to have built-in array (1D) and matrix (2D, 3D) datatypes, instead of simply the 'derivedBy = list' mechanism.

If these cannot be provided then the alternative is to use lists. In the current WD, you can only create lists from atomic data types and since a list is not an atomic data type then you cannot create matrices using 'lists of lists' e.g.:

Alternatively we can simply convert matrices to flattened lists which can be 1D, 2D or 3D and use a dim facet to lists to specify multi-dimensionality:

James Tauber <JTauber@bowstreet.com> to XML Schema Comments list, Tue, 2 May 2000 21:09:11 -0400

In 4.3.1, in the second scenario (where ref is absent and schema is not the parent) the value of {value constraint} is given as "fixed" if the "use" attribute is not "default".

In other words, if a value is given, but the use attribute is one of "optional", "fixed" or "required", the value constraint is taken to be "fixed".

Is this correct?

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 03 May 2000 09:26:50 +0100

There's a co-occurrence constraint missing, you're right. There should be something under Attribute Declaration Representation OK which says "if 'value' is present, then 'use' must be "default", "fixed" or "required".

Peter Canning <canning@vitria.com> to XML Schema Comments list, Tue, 02 May 2000 20:31:45 -0700

The structure specification identifies some schema component properties (e.g. the "min occurs" property in the "Attribute Declaration" component) as optional and states (section 3 paragraph 1) that optional properties that are missing have "absent" as their value. It also describes some properties (e.g. the "target namespace" property in the "Attribute Declaration" component) as mandatory, but includes "absent" in the list of legal values.

What is the difference between an optional property, and a mandatory property whose value can be "absent"?

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 03 May 2000 09:34:30 +0100

Peter Canning <canning@vitria.com> writes:

Good question. I think (leaving aside the question of what happens when a required property is absent without leave because of a failed reference) that {target namespace} is the only such property, and we should revisit the nomenclature here. There was a change in terminology in this area very late in the publication process, and some more work needs to be done.

The intended distinction is that {target namespace} is always relevant, it value always significant, even when it is the 'absent' value == no namespace. For e.g. {min occurs}, there are circumstances, e.g. for top-level attribute declarations, where the property is irrelevant, the value never looked at and hence not supplied.

Curt Arnold <carnold@houston.rr.com> to XML Schema Comments list, Tue, 2 May 2000 22:33:01 -0500

Section 2.3

Among these, the enumeration facet is one of the most useful and it can be constrain the values of almost simple type, except the boolean type.

Why not the boolean type? xsi:null appears to use an enumerated boolean (allowing true but not 1). Anyway, I believe that xsl:null should accept false, 0, true and 1. With only true and 1 signifying null content.

Curt Arnold <carnold@houston.rr.com> to XML Schema Comments list, Tue, 2 May 2000 22:33:01 -0500

Section 2.3

(you cannot create lists from complex types).

For the narrative, I think it is probably more appropriate that you mention lists can't be derived from other list types.

Curt Arnold <carnold@houston.rr.com> to XML Schema Comments list, Tue, 2 May 2000 22:33:01 -0500

3.4 Undeclared target namespaces

I have a problem with this. If you are going to the point of defining a schema, these elements and attributes are in a conceptual namespace whether or not you give it a name. The way targetNamespace is defined, I cannot write one schema that could be used to validate a XML 1.0 sans namespace document and also used in a to validate a document with namespace support. I can't even use include since the targetNamespaces wouldn't match.

What I would recommend is that targetNamespace be required for schema definition. However, the XML 1.0 binding mechanism could specify both a validation namespace and schema location. The noNamespaceSchemaLocation could be a list of two URI's with the first being the validation namespace and the second being the schema location.

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 03 May 2000 09:29:50 +0100

Curt Arnold <carnold@houston.rr.com> writes:

... The way targetNamespace is defined, I cannot > write one schema that could be used to validate a XML 1.0 sans namespace > document and also used in a to validate a document with namespace support.

That's precisely what you can do. Write the schema with no targetNS, it can be used as is for no-namespace documents, and included into schemas with a targetNS and thereby appropriated for use with that target.

Curt Arnold <carnold@houston.rr.com> to XML Schema Comments list, Wed, 3 May 2000 09:39:09 -0500

Primer Section 4.1 said:

The one import caveat to using the include is that the target namespace of the included constructions must be the same as the target namespace of the including schema... Maybe this is imprecise and Section 1 allows the included target namespace to be blank.

However, even if you could use the include to achieve reuse, it is still a bad thing to have to publish two near-identical schemas, one for use in XML 1.0 sans Namespace usage and one for namespace aware usage. This is really a distinction in usage and should be addressed in the binding of a schema with a document and not in the schema itself.

For example, you would have to have two schemas for XHTML. Both would truely be using names within the context of the http://www.w3.org/1999/XHTML (whatever the true namespace is), but one would be for XML 1.0 compatible documents and one for XML 1.0+namespaces. This is just not good.

However, simply moving the statement of which namespace to match with unnamespace qualified elements to the binding of the document and schema allows you to use one schema for both XML 1.0 and XML+Namespaces usages.

"Curt Arnold" <carnold@houston.rr.com> to XML Schema Comments list (and xml-dev) on Thu, 11 May 2000 01:19:19 -0500

Note on defaultNamespace:

A previous comment (http://lists.w3.org/Archives/Public/www-xml-schema-comments/2000AprJun/0124.html) discussed Section 3.4 on Undeclared target namespaces. The current treatment would require one schema for XHTML, for example, for documents where the namespace was declared and another schema for XHTML where the namespace was not declared. To me, it seems that the creation of a schema implies that you are defining elements that are in a conceptual namespace and that the additional burden of picking out a URI for this namespace is minimal. If a instance document doesn't want to use an xmlns attribute, that is a usage issue that could be addressed by a xsi:defaultNamespace attribute (or schema PI) that provides a weaker binding of unqualified names to a namespace that is only used for schema validation.

Curt Arnold <carnold@houston.rr.com> to XML Schema Comments list, Tue, 2 May 2000 22:33:01 -0500

4.2 Deriving Types by Extension

Furthermore, the two content models are treated as two children of a sequential group.

I actually prefer this behavior, but it might be out of synch with our recent discussion about behavior when the base type has content model mixed.

"Steven Pemberton" <steven.pemberton@cwi.nl> to XML Schema Comments list, Wed, 3 May 2000 15:17:30 +0200

The HTML WG has requested me to relay to you a request that XML Schemas include a facility to define at least character entities (such as é).

While we recognise that the full entity mechanism might be a burden, HTML markup typically contains a lot of character entities, and we would like to be able to define them when using schemas without having to fall back to a DTD subset.

Dan Connolly <connolly@w3.org> to XML Schema Comments list, Fri, 05 May 2000 08:44:04 -0500

Steven Pemberton wrote: The HTML WG has requested me to relay to you a request that XML Schemas include a facility to define at least character entities (such as &eacute;).

We tried that before, but it didn't work out well; we weren't sure we liked it, but we put the idea out for review, and the feedback was overwhelmingly negative:

"The provision within XML Schema: Structures of a mechanism for defining parsed entities presents problems for the relationship between schema-validity and XML 1.0 well-formedness, since references to entities defined only in a schema are undefined from the XML 1.0 perspective. Strictly speaking, a well-formed XML document may contain references to undefined entities only if it is declared as standalone='no' and contains either an external subset or one or more references to external parameter entities in their internal subset. We get around this by [Definition: ] defining a nearly well-formed XML document to be one which either is well-formed per XML 1.0, or which fails to be well-formed only because of undefined general entity references, but which would be well-formed if it were standalone='no' and identified an external subset. We consider this justified on the grounds that the use of a namespace declaration which refers to a schema functions rather as an external subset, and from the XML 1.0 perspective such a reference almost of necessity renders the document non-standalone when schema-validation is applied."

-- http://www.w3.org/1999/05/06-xmlschema-1/#conformance-schemaValidity

If you can think of a less awkward way to do it, let us know.

Otherwise, I think it's most likely that the WG will decline your request.

If you find this explanation to be satisfactory justification for us to decline your request, please let us know by withdrawing your request.

While we recognise that the full entity mechanism might be a burden, HTML markup typically contains a lot of character entities, and we would like to be able to define them when using schemas without having to fall back to a DTD subset.

I'm afraid that's about the only way I can see to make it work.

Another option is to use <eacute/> instead of é, but that requires application-level support rather than being handled by the XML processor, and it won't work in attribute value literals.

"Dr. Ardeshir Bahreininejad" <bahreininejad@yahoo.com> to XML Schema Comments list, Wed, 3 May 2000 07:57:59 -0700 (PDT)

I wish to define an element in a schema document where the "name" of the element is not known. Let's say, the name of the element may be decided by other parties using the schema for example:

where a different user may decide on the ????. How do we define such dynamic name allocation?

"Vun Kannon, David" <dvunkannon@kpmg.com> to XML Schema Comments list, Wed, 3 May 2000 12:04:24 -0400

Can I build a datatype out of pieces that are disjoint? A simple example might be US_states + Canadian_provinces. Say my schema already contains declarations of these two enumerations. The new enumeration I want is the merger of the two. I don't want to extend one with the members of the other, explicitly written out.

A more complex case is SQL style datatypes: integer + NULL. Can I build such a datatype in XSchema?

petsa@us.ibm.com to XML Schema Comments list, Wed, 3 May 2000 13:12:49 -0400

No, sorry, not in version 1.

You cannot create a type out of the union of disjoint types, say, integer and string.

You also cannot union two separately declared enumerations.

"Asir S Vedamuthu" <asirv@webmethods.com> to XML Schema Comments list, Thu, 4 May 2000 09:59:09 -0400

I am having a hard time to understand - how to evaluate 'The item type definition is validly derived from the {type definition}'. And, here is the text from the spec, http://www.w3.org/TR/xmlschema-1/#coss-ct

"Constraint on Schemas: Type Derivation OK (Complex)

A complex type definition (call it D, for derived) is validly derived from a type definition (call this B, for base) given a subset of {extension, restriction} if:

Please help me understand (maybe an example) & I greatly appreciate your help.

Formal response to commentator.

Jane Hunter <jane@dstc.edu.au> to XML Schema Comments list, Fri, 05 May 2000 09:54:28 +1000

We're using XML Schema within MPEG-7 to define descriptions of audiovisual content. Certain descriptive elements have a language attribute. For consistency, we'd like to use the xml:lang attribute.

Does this need to be declared like any other attribute for the elements to which it applies? For example:

I assume that we also need to import the xml namespace? If so, where is this located?

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 05 May 2000 09:07:59 +0100

There is an example of this in the schema for schemas [1] itself, which also uses xml:lang.

Short answer, it's at the XML namespace URI, i.e. http://www.w3.org/XML/1998/namespace

Curt Arnold <carnold@houston.rr.com> to XML Schema Comments list, Fri, 5 May 2000 00:05:30 -0500

Section 2.2.2.2

All such members must have type definitions which are either the same as the exemplar's type definition or restrictions or extensions of it. Therefore, although the names of elements can vary widely as new namespaces and members of the equivalence class are defined, the content of member elements is strictly limited according to the type definition of the equivalence class exemplar

This implies that the justification for the constraint is somehow related to simplification of validation because content is strictly limited....

However, this "limitation" is circumventable by creating an abstract examplar with a minimal type such as empty.

By which we have created an equivClass with two members that are about as structurally dissimilar as possible. I think it is a good thing to be able to do that since it should be common, as in this example, that logically equivalent things have radically different XML representation.

But then why go through the hoops of manufacturing a common ancestor type? I have a guess that it is so that final='restriction' or final='extension' makes sense, but that I think that is putting the cart before the horse.

Like the concept of interfaces in OOP, equivClass's reason for being is to allow structurally dissimilar but conceptually similar items to be substitutable. Interfaces do not make any demands on the structure of the implementing class and one class may support many interfaces.

I would strongly recommend that:

I believe this would simplify schema authoring by eliminating the manufacturing of common ancestor classes, would simplify schema validation by eliminating the need to ensure common ancestor classes and would be consistent with the use of interfaces in OOP.

Doug Ransom <Doug_Ransom@pml.com> to XML Schema Comments list, Fri, 5 May 2000 11:53:52 -0700

I think would be very unfortunate if Integer and NonNegative integer could not have hex lexical structure. i.e. 0xffaa00bb instead of 4289331387.

Binary is really inapprpriate for this -- people often want to represent numbers as hex (i..e HTML colours).

"gmacri@libero.it"<gmacri@libero.it> to XML Schema Comments list, Sat, 6 May 2000 14:20:01 +0200

In this example there are three declarations of namespace and two declaration of schemalocation that are independent.

When I analyze this document with an application (automatically), how I can understand that, for example, for "Book" element I must search it in the schema "Book.xsd" and not in "Person.xsd", to verify the validity of this document?

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 08 May 2000 08:58:58 +0100

The above document is just fine even if it doesn't in itself provide the answer to your question for a processor. The <Book> element is in the {http://www.somewhere.org/Book} namespace, for which no schema document is identified explicitly in the value of xsi:schemaLocation. That doesn't mean the document is not schema valid. Note also that the document element (<Library>) is not in any namespace, and no schema is provided explicitly (with xsi:noNamespaceSchemaLocation) for that element either.

But there are at least two other ways schema components for these elements might be found:

"gmacri@libero.it"<gmacri@libero.it> to XML Schema Comments list, Mon, 8 May 2000 14:24:33 +0200

In this example there is a definition of a key:

If I want to define a key similar to the key defined above, can I use as content of <field> a name of element that is not a descendant of "car" but is a name of an element that is, for instance, the child of an ancestor of car?

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list, 08 May 2000 14:52:50 +0100

Yes. As the spec. says [1], the things picked out by <field> are not constrained to lie within the element picked out by <selector>, and no other constraint as to locality is imposed.

[1] http://www.w3.org/TR/xmlschema-1/#Identity-constraint_Definition_details

"Smith, Michael K" <michael.smith@eds.com> to XML Schema Comments list, Mon, 8 May 2000 13:59:09 -0500

In '3.8 Particle Details':

The 'either' preceding paragraphs 1.1.1 through 1.1.3 (see below) and 1.2 is confusing. It initiallly appears that 1.1.1 through 1.1.3 are modified by the 'either', while upon further reading they must be joined by an implicit 'and' and the 'either' relates the implicit 1.1 to 1.2. I don't know what the best solution to this might be, perhaps parenthesis or an explict 1.1 with an 'and' conjoining its children. Perhaps your notational introduction explained this, but I didn't see it.

A sequence (possibly empty) of element information items is schema-valid with respect to a particle if either

1.1.1 The length of the sequence is greater than or equal to the {min occurs};

1.1.2 If {max occurs} is a number, the length of the sequence is less than or equal to the {max occurs};

One aspect of this separation of 1.1.1 and 1.1.2 that seems less than optimal is that it makes it easy to define a schema that cannot be satisfied. E.g. minOccurs = 2 and maxOccurs = 1. (Such schemas might be generated mechanically, say from database entries.) Whereas if 1.1.1 and 1.1.2 were combined we could at least have a schema that could be satisfied by instances that did not contain the excluded element.

1.1.1 Let range = [{min occurs}...{max occurs}]. If range is empty then the sequence must be empty, otherwise the length of the sequence must be contained in the range.

In section 3.9, it is explained that: "the {namespace constraint} property (for a wildcard) provides for validation of elements that: 3. (not and absent} are namespace qualified."

I assume that it is also true for attribute wildcard. I look at the XML representation of Wildcard and it does not seem obvious how to express something like " any attribute with qualified namespace". Maybe the XML representation of wildcard should allow something like <any namespace="##qualified"/> (and for Attribute wildcard <anyAttribute namespace="##qualified"/>) which will correspond to the {namespace constraint} = (not and absent).

Anders W. Tell (<anderst@toolsmiths.se>) to WWW XML Schema Comment list on Wed, 10 May 2000 09:47:27 +0200

Problem:

A common phenomena which now and then surfaces in the markup world is the occurrence of what some authors call "Micro-parsing". This is the situation when Schema writers define that a XML attribute should contain structured information and therefore creates a need for customized parsers, hence the above term.

Two examples are

Is this not a paradox? A markup language which cannot be used for markup anymore? Of course all markup languages have a limit and maybe XML's limit have been reached.

Why:

What are the reasons for encoding complex information in a single attribute ?

The reason I have seen are sofar are:

The following suggestions is an attempt to "internalize" these encoding scenarios, to capture as much as possible of the encoding information inside XML Schemas instead of relying on externally created and managed documentation.

Another side effect of the proposal is that it's now possible to have DOM access to structured attributes as if they were XML element encoded.

For Grove enthusiasts it is also possible to view (with a little effort ;)) attributes as hierarchical nodes.

So here goes...

Solution:

First a few initial short definitions:

Encoding "Stereotype" <=> something that should be encoded, is defined by a information model which may be defined in terms of one or more information items (nodes/properties,...).

Encoding "Form" <=> principles for how nodes/properties in an Stereotype's information model must be encoded as a strings or XML elements. (the following suggestion implies two forms, one for attribute encoding and one for XML element encoding)

"Attribute-Micro-Parser" <=> A software artifact which encodes and decodes XML attribute strings to/from XML elements.

Michael Anderson <michael@research.canon.com.au> to XML Schema Comments list (and xml-dev) on Wed, 10 May 2000 11:01:32 +1000

Is it possible to define a new simple type to constrain the pattern of a time duration so that duration can at most be measured in days. For instance,

According to the XML Schema working drafts, the pattern facet is allowed for timeDuration. My interpretation is that any pattern facet, once specified for a subtype of the timeDuration type, can further restrict the format of timeDuration provided that it is still of a valid timeDuration format. Is this correct? Furthermore does the parser need to check this? ie check that the pattern of MyTimeDuration is indeed still a valid pattern for timeDuration.

Cheers, Michael.

"Joseph M. Reagle Jr." <reagle@w3.org> to XML Schema Comments list on Wed, 10 May 2000 12:48:18 -0400

http://www.w3.org/Signature/2000/05/03-schema-review.html

The XML Signature WG thanks the XML Schema WG for their work and the opportunity to review the last call Working Draft [1]. This comment does not address the ease of implementation but only whether the functionality as specified meets our requirements. To that end, the last call specification easily meets our requirements. In particular, the content types (elementOnly | empty | mixed | textOnly) and the Wildecard Schema Component <ANY/> are very useful for dealing with mixed content scenarios which are common to the signature domain. In time, the type extension capabilities might be a useful feature in constructing other cryptographic (key and certificate) syntaxes but we are presently not employing these typing features.

Since the XML Signature specification should enter the W3C Recommendation and IETF Standard tracks soon, we ask that the schema WG give priority to the need for a stabilized syntax and for expediently advancing the schema specification towards Recommendation.

Joseph Reagle, on behalf of the XML Signature WG

[1]

"Joseph M. Reagle Jr." <reagle@w3.org> (on behalf of XML Signature WG) to XML Schema Comments list on Wed, 10 May 2000 12:48:18 -0400

Since the XML Signature specification should enter the W3C Recommendation and IETF Standard tracks soon, we ask that the schema WG give priority to the need for a stabilized syntax and for expediently advancing the schema specification towards Recommendation.

"Joseph M. Reagle Jr." <reagle@w3.org> to XML Schema Comments list on Wed, 10 May 2000 12:48:14 -0400

2.2 XML Schema Abstract Data Model

I could understand this chapter better if the 12 components listed somehow corresponded more closely to the 2.2.* section headings. Perhaps, a quick definition on each of the 12 components, or a move away from the "primary" and "secondary" and "helper" designations (towards others) if those terms aren't substantively used elsewhere.

"Joseph M. Reagle Jr." <reagle@w3.org> to XML Schema Comments list on Wed, 10 May 2000 12:48:14 -0400

Namespace Prefixes

When trying to understand the specifications, I frequently found myself bouncing between the primer, structures, and datatypes documents, frequently using find or grep facilities to find bits of examples. Using a consistent namespace prefix (xs: or xsd:) through all documents would be helpful.

"Joseph M. Reagle Jr." <reagle@w3.org> to XML Schema Comments list on Wed, 10 May 2000 12:48:14 -0400

2.6 Schema-Related Markup in Documents Being Schema-Validated

Could the Schema Instance namespace somehow relate to the Schema namespace? For instance, I'd find it easier to understand who defined the schema instance namespace with something like:

"Joseph M. Reagle Jr." <reagle@w3.org> to XML Schema Comments list on Wed, 10 May 2000 12:48:14 -0400

Appendix A (normative) Schema for Schemas

It would be useful for XML declarations to include more explicit declarations of DTD and schema locations. For instance:

Defaults

The more explicit representation of default values in schema component definitions is useful. However, the many varied defaults can still be confusing, perhaps this could be simplified, or a table could be provided that includes all default values.

"Joseph M. Reagle Jr." <reagle@w3.org> to XML Schema Comments list on Wed, 10 May 2000 12:48:14 -0400

Defaults

The more explicit representation of default values in schema component definitions is useful. However, the many varied defaults can still be confusing, perhaps this could be simplified, or a table could be provided that includes all default values.

"Joseph M. Reagle Jr." <reagle@w3.org> to XML Schema Comments list on Wed, 10 May 2000 12:48:14 -0400

3. Advanced Concepts I: Namespaces, Schemas & Qualification

This topic (not necessarily the exposition) is difficult to comprehend with respect to both comprehending the concepts and as a potential source of validation errors in instances I create. Perhaps some guidelines such as, "If you want to create an instance that has no prefixes in children elements then X; if you want to create an instance ... Y" so readers can easily jump-start their own schema writing.

Bob Schloss <rschloss@us.ibm.com> to XML Schema Comments list on Wed, 10 May 2000 19:42:22 -0400

My understanding is that Unique Particle Attribution constraint is so that parsers do not have to lookahead.

If I define a complex type as follows:

is this permitted (a legal type definition)?

I could imagine the answer is yes, because a parser doesn't have to look ahead during parsing.

I could imagine the answer is no in the case where the equivalence classes of c and of b are not completely independent, but only because the first sequence requires that d follow b.

If this second thought is the one intended by the working group, shouldn't Structures appendix E say something about this under 'Unique Particle Attribution'?

Here is a different case:

If I define a complex type as follows:

is this permitted (a legal type definition)?

Does this depend on whether there is a common parent type for typeOfA1 and typeOfA2 other than the ur-type? (Since if there was, and the xsi:type attribute was not used on the a element in the instance document with a value of either typeOfA1 or typeOfA2, the parser would have to look ahead before determining which branch of the choice was being processed).

I think the general problem related to choices (which may contain choices, which may contain choices) which contain sequences.

Here is a third case:

If I define a complex type as follows:

is this permitted? I don't think it is, because a choice of choices is like flattening to one choice, and then there are 2 different types that can appear with element a. (Appendix E does rule out this if the user had it flattened, and in Section 5.7 on model groups, I think this is covered by Element Declarations Consistent). But this still seems to me that a "Also see..." in Appendix E should cover this case.

I guess I'm asking for clarification of these examples now, and also that Appendix E be more complete in the next spec working draft.

Susan Lesch <lesch@w3.org> to XML Schema Comments list on Wed, 10 May 2000 19:41:36 -0800

These are just a few minor editorial comments on your Last Call draft, XML Schema Part 1: Structures "work in progress." Please feel free to ignore or use them as you see fit.

In the interest of advancing schemas in practice, perhaps in the Abstract or in Introduction section 1, you could identify your audience, encourage them, and (like MathML) explain that this is not a user's guide for the general public. This specification is carefully and beautifully done, but it was a mystery for me on one reading, even after reading the Primer.

Both Webster's (en-US) and the concise Oxford dictionaries list the "z" rather than the "s" form of these words first: normalisation, normalised, optimise, standardised, and characterisation. They could be changed to z's.

The text does not refer to most of the References (Cambridge Communique, DCD, DDML, ISO-11404, and so on). I'm not certain they need to be there, especially the old URI RFCs.

Though I didn't correct this here, apparently the use of "we" is frowned on in specifications. I don't yet have a proper reference for you. One reason is in the final paragraph of http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMa r/0079.html which explains that first person English is hard to translate.

muzmo.com and foo.com are registered domains. You could consider using example.com, example.net, and example.org which IANA registered for examples. (See RFC 2606 section 3 at http://www.ietf.org/rfc/rfc2606.txt.)

Minor typos (quotes are followed by a suggestion)

2.2.1.3 par. 1 with respect to particular simple type → with respect to a particular simple type

2.2.1.3 par. 2, list items 1 and 3 A restriction → a restriction

3.4 table - {content type}, and 3.4 par. 11, and 3.13 par. 7 I.e → i.e.,

3.7 par. 3 {compositor}determines → {compositor} determines

3.13 par. 11 . therein. → .

4.3.3 table {content type} 4.4.2.3 the the → the

5.1 list item 4 has a subheading 4 (that should perhaps be 4.1 or 1).

In 5.11, the first sentence is repeated in the third line

5.11 note in 1.1.6 It is trivially → It is trivial

6.3.1 par. 1 mime → MIME

6.3.2 list item 2 note, and 6.3.2 last par. recommendation → Recommendation

B. line 3 The the → The

B. line 172 exculsive → exclusive

D. HTML 4.0 Specification → HTML 4.01 Specification

RFC 1808,Relative → RFC 1808, Relative

RFC 1738,Uniform → RFC 1738, Uniform

RFC 2141,URN → RFC 2141, URN

XSchema c/xscspecv4.htm For more → c/xscspecv4.htm. For more

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list on 11 May 2000 10:23:47 +0100

Thanks for your careful reading.

Susan Lesch <lesch@w3.org> writes:

These are just a few minor editorial comments on your Last Call draft, XML Schema Part 1: Structures [1] "work in progress." Please feel free to ignore or use them as you see fit.

In the interest of advancing schemas in practice, perhaps in the Abstract or in Introduction section 1, you could identify your audience, encourage them, and (like MathML) explain that this is not a user's guide for the general public. This specification is carefully and beautifully done, but it was a mystery for me on one reading, even after reading the Primer.

Good idea.

Both Webster's (en-US) and the concise Oxford dictionaries list the "z" rather than the "s" form of these words first: normalisation, normalised, optimise, standardised, and characterisation. They could be changed to z's.

I'll check my UK dictionary -- as a UK (naturalised :-) speaker, I've used UK spelling throughout.

The text does not refer to most of the References (Cambridge Communique, DCD, DDML, ISO-11404, and so on). I'm not certain they need to be there, especially the old URI RFCs.

Right.

Though I didn't correct this here, apparently the use of "we" is frowned on in specifications. I don't yet have a proper reference for you. One reason is in the final paragraph of http://lists.w3.org/Archives/Public/www-xml-linking-comments/2000JanMar/0079.html which explains that first person English is hard to translate.

But I hate the academic passive, which is the obvious alternative . . .

muzmo.com and foo.com are registered domains. You could consider using example.com, example.net, and example.org which IANA registered for examples. (See RFC 2606 section 3 at http://www.ietf.org/rfc/rfc2606.txt.)

Agreed.

"Curt Arnold" <carnold@houston.rr.com> to XML Schema Comments list on Wed, 10 May 2000 23:56:29 -0500

Part 1/Section 3.4

A complex type for which {abstract} is true must not appear as the {type definition} of an ElementDeclaration...

Actually, it would seem that you would allow it, but it would require that the xsi:type specify a non-abstract type derived from the type used in the declaration.

Part 1/Section 4.3.7

Wildcards are subject to the same ambiguity.... If an instance element could match either an explicit particle and a wildcard, or one of two wildcards, within the content model of a type, that model is in error.

If I had version 1.0 of a schema and wanted to create a variant that would be forward compatible for a processing application (so that the processing application would accept 1.0 valid documents and later revisions), I'd be inclined just mechanically add <any> and <anyAttribute> elements, like:

Unfortunately, this would run into the Unique Particle Attribution issue and would be in error by my reading. In this simple case, it is fairly easy to rewrite the permissive complexType as:

However, that could be much more difficult in complex real-life schemas. Some sort of lower priority for wildcard matches that would allow the first formulation while avoiding the attribute issue would be beneficial.

Constraint on Schemas: Particle Restriction OK (Elt:Elt - Name and Type OK)/Point 1.1

{nullable} are the same: wouldn't it be a valid restriction if the base type was nullable and the derived type inhibited xsi:null="true"

Section 5.11/Constraint on Schemas: Derivation Valid (Extension)/Point 1.1.2

Either I'm reading it wrong, or it is saying that you must fully repeat all the attributes defined in the base type in the derived type.

Point 1.2.2

So if I have:

Does this still allow any other attribute to appear, but value is required? If so doesn't that run into the Unique Particle Attribute issue.

Point 1.3:

Is this saying that if my base type definition has a required attribute, I have to repeat in a derived by restriction type?

Section 5.12/Constraint on Schemas:Derivation Valid

Point 1.2(.1?) This would seem to disallow adding new facets in the derived type

"Curt Arnold" <carnold@houston.rr.com> to XML Schema Comments list on Thu, 11 May 2000 00:08:22 -0500

Section 6.2.2: References to schema components across namespaces

The comments in the example are the only place that I have found that indicate how unqualified QName references are to be resolved. From a usability standpoint, it would be much preferable to that an unqualified name be first attempted to be located within the target namespace then with the datatypes (or schema namespace). This, of course, would be a more complex resolution than would be used for a unqualified tagname but seems to be consistent with previous usage.

If unqualified names are strictly going to be resolved this way, an explicit statement should be made prominently in both Primer and Part 1.

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list on 11 May 2000 10:26:34 +0100

They wouldn't be QNames in the meaning of the word if we did it that way. We didn't think it wise to invent a new concept almost-QName-but-not-exactly.

"Curt Arnold" <carnold@houston.rr.com> to XML Schema Comments list (and xml-dev) on Thu, 11 May 2000 01:19:19 -0500

Section 6.3.2: Point 4

Having declarations of schemaLocations anywhere in the document having document scope, of course, seriously complicates event-based validation. It would seem reasonable to require that schemaLocations appear before the need for the corresponding schema information.

"Curt Arnold" <carnold@houston.rr.com> to XML Schema Comments list (and xml-dev) on Thu, 11 May 2000 01:19:19 -0500

In general, I think locating schema resources has a couple of serious deficiencies.

First, there is not a one-to-one correspondence between namespaces and schemas. For example, the XHTML namespace has three distinct DTD's associated with it which are distinguished using public identifiers. There may also be successive versions of schemas for the same namespace.

Second, a single schema resource may contain many distinct (possibly tens if not hundreds) namespaces through inclusions. I believe the typical usage would be to have a single schema resource that would contain definitions for all the expected namespaces and then, occassionally, one or more additional schema resources for unanticipated namespaces. Having to enumerate all the namespaces that appear in a mega resource would get very long and prone to error.

Third, there is not a conflict resolution mechanism when a namespace has multiple schema locations are declared either implicitly (through an import within a schema) or explicitly through a schemaLocation attribute.

Fourth, there is not a mechanism to identify a schema resource to be used to validate an XML 1.0 (pre-namespace) compatible document.

It would seem the best approach would be to use public identifiers (fortunately having a rebirth of interest on xml-dev) to explicitly identify a specific schema resource instead of relying on an ambiguous combination of namespace and namespaceLocation to resolve whether a particular cached version of a schema is appropriate.

What I would suggest is that:

When xsi:schemaPublic and xsi:schemaSystem appear on the same element, there must be a one to one correspondence between entries, so that if the second public identifier cannot be resolved, the second URI could be used to retrieve the resource. I'm assuming that there can be an acceptible mechanism for representing a null public identifier and a null URI.

When schema information appears for one namespace in multiple schema resources, the first appearance would be used for validation.

"Martin J. Duerst" <duerst@w3.org> to XML Schema Comments list on Thu, 11 May 2000 16:53:52 +0900

This review deals with the suitability of XML Schema to describe the constructs used in XML-DSig (Schema/DTD).

What is missing, and what I would hope the XML DSig group could contribute significantly to, is some kind of analysis e.g. with respect of what potentials and problems XML Schema offers with regards to describing data that can easily be signed. Two examples:

In other words, try to make sure that for appropriately designed XML Schemas, no additional 'data canonicalization' step is necessary to sign some data.

What do the DSig experts in this group think about such issues?

"Joseph M. Reagle Jr." <reagle@w3.org> to XML Schema Comments list on Thu, 11 May 2000 13:00:22 -0400

At 04:53 PM 5/11/00 +0900, Martin J. Duerst wrote: Because the 'boolean' datatype has four lexical values (true, false, 1, 0; this is in the spec, no kidding) instead of two lexical values, that means that additional effort (at least) is necessary if somebody wants to create a schema for some data containing boolean values.

Martin, thank you for reminding me about this. I recall you've mentioned this before and I believe we had an agreement from Michael to do something about ensuring a consistent lexical representation of data types. I can't find a URL for that agreement (I think it was sometime last year) but I can find evidence that the WG was trying to satisfy that requirement (for floating points at least):

3.2.3 - 3.2.5 Lexical notation of floating-point numbers [Where the author requested other notations] This argument was made by several people but there was a strong sentiment for a single lexical representation. http://lists.w3.org/Archives/Public/www-xml-schema-comments/2000AprJun/0043.html

However, I'm not sure to what extent this is a problem (I'm expressing ignorance, not arguing it isn't). If an XML instance uses '0' that is signed, is there and expectation that since the schema permits a 'false' as well, intermediary processors would change it? I appreciate this might happen with character code mappings, but I tend to view schema's as constraints on permissible values, and not a processor (in the vein of infoset/C14N/DOM). (For instance, just because a schema permits an unconstrained string, one wouldn't presume it would change the string ...?)

I don't quite follow. Element of the same element type? Can you give an example?

"Martin J. Duerst" <duerst@w3.org> to XML Schema Comments list on Fri, 12 May 2000 16:38:15 +0900

However, I'm not sure to what extent this is a problem (I'm expressing ignorance, not arguing it isn't). If an XML instance uses '0' that is signed, is there and expectation that since the schema permits a 'false' as well, intermediary processors would change it?

Not necessarily, but that may well happen. We already see in the DSig group that people want to use the DOM, and don't want to keep around e.g. whether an attribute was single-quoted or double-quoted. As we move up the semantic ladder (well, it feels more like a very flat slope, but that's a different issue), exactly the same will very easily happen one step higher.

I appreciate this might happen with character code mappings, but I tend to view schema's as constraints on permissible values, and not a processor (in the vein of infoset/C14N/DOM).

Constraints on permissible values is one function, and probably the most important one the way the spec is written. But for datatypes, the 'infoset' aspect is already there, and C14N is what we are just discussing here, and would be very very easy to add at this point in time compared to having to start another group,... in a few months. Something like DOM is not done yet, but conversion from data to XML streaming and back is an important application of XML Schema, probably the most important one.

(For instance, just because a schema permits an unconstrained string, one wouldn't presume it would change the string ...?)

There is a clear difference between changing the value, and producing a different lexical representation for the same value. Changing from 0 to false is the later, changing the string is the former.

I don't quite follow. Element of the same element type? Can you give an example?

Well, let's assume you have a list of students, with student id, birthday, and a boolean for 'male' (gender). The task is to produce a signable XML document from this data. In order for the sign to be reproducable, the XML document has to be exactly the same for the same data. Assuming that the structure looks something like

and is described as an XML Schema, the 'missing pieces' for the above task are to make sure the students are always in the same order (e.g. by id) and that date and boolean are always in a canonical form (and of course that the underlying XML is in C14N).

Probably the above is not the most appropriate example, but I hope you get the idea.

"John Boyer" <jboyer@PureEdge.com> to XML Schema Comments list on Fri, 12 May 2000 09:42:08 -0700

<martin> Not necessarily, but that may well happen. We already see in the DSig group that people want to use the DOM, and don't want to keep around e.g. whether an attribute was single-quoted or double-quoted. As we move up the semantic ladder (well, it feels more like a very flat slope, but that's a different issue), exactly the same will very easily happen one step higher. </martin>

<john> Actually, I'm pretty sure we would argue that if you want to schema normalize an XML document, then you would need another transform for that. Whether we define such a transform in this version of the spec is a decision of the chairs.

"Martin J. Duerst" <duerst@w3.org> to XML Schema Comments list on Sun, 14 May 2000 11:49:02 +0900

At 00/05/12 09:42 -0700, John Boyer wrote: <john> Actually, I'm pretty sure we would argue that if you want to schema normalize an XML document, then you would need another transform for that.

Can you give some examples for what you mean by 'schema normalize', i.e. a short document before and after normalization, or so?

What I'm saying is that with some rather minor tweaks to the current Schema drafts, it will be possible to easily write Schemata that will make sure that documents that validate against these Schemata will already be normalized and won't need any normalzation on the schema level anymore.

Whether we define such a transform in this version of the spec is a decision of the chairs.

How could such a transformation look?

"gmacri@libero.it"<gmacri@libero.it> to XML Schema Comments list on Thu, 11 May 2000 14:20:06 +0200

When I write a XML schema, for instance schema1.xsd, in which is included another schema, schema2.xsd, the elements's, attributes's and types's name of child of schema1.xsd must be not equal at elements's, attributes's and types's name of child of schema2.xsd?

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list on 11 May 2000 15:19:27 +0100

That's correct, assuming you mean elements, attributes and types declared at the top level.

petsa@us.ibm.com to w3c-xml-schema-ig@w3.org and others, Wednesday, May 03, 2000 2:39 PM

"Asir S Vedamuthu" <asirv@webmethods.com>@w3.org on 05/03/2000 01:36:48 PM

(1) <Snip> Section 3.3.8 integer http://www.w3.org/TR/xmlschema-2/#integer

Integer has the following constraining facets: precision, scale, .. </Snip>

Please explain the validation contribution of 'precision' & 'scale' if the {base type definition} is integer.

Integer is derived from decimal by setting scale=0 The PSV infoset for derived datatypes indicates all the facets of the base datatype and their fixed values.

(2) <Snip> Section 3.2.6 timeDuration http://www.w3.org/TR/xmlschema-2/#timeDuration

.. where nY represents the number of years, nM the number of months, .. </Snip>

<Snip> Section 4.2.6 - 4.2.9

.. if the {base type definition} is one of date and time related datatypes, then the value must be chronologically less than or equal to {value} </Snip>

'nY' - Does a year have 360 or 365 days?

'nM' - Does a month have 28, 30, 31, or 400 days?

Note: I scanned thru ISO 8601 and it does not say anything about it

The number of days in the month or year will depend on when the period occurs. We take the position that this is always known and, thus, there is no ambiguity but would like to see counterexamples. ISO8601 seconf edition, does say in 3.15 that "in certain applications a month is regarded as a unit of time of 30 days".

(3) <Snip> Section 4.2.1 length http://www.w3.org/TR/xmlschema-2/#dc-length Constraint on Schemas: length and minLength - it is an error for both length and minLength to be members of {facets} </Snip>

Is it ok if length and maxLength are members of {facets}?

No, if length is specified neither minLength or maxLength can be specified.

(4) <Snip> Sectin 4.2.6 maxInclusive http://www.w3.org/TR/xmlschema-2/#dc-maxInclusive Constraint on Schemas: It is an error for the value specified for minInclusive to be greater than the value specified for maxInclusive for the same datatype</Snip>

Is it ok if minExclusive to be greater than maxInclusive? This question also applies to Section 4.2.7 - 4.2.9

No.

(5) <Snip> Section 4.2.5 enumeration http://www.w3.org/TR/xmlschema-2/#dc-enumeration [value] a set of values from the value space of the {base type definition}</Snip>

Lets say I have a <simpleType/> A that restricts a {base type definition} B. In addition, <simpleType/> A has a set of <enumeration> values, say e1, e2, e3, .., en. Is the set {e1, e2, .. } of values form the value space of {base type definition} B or <simpleType/> A? Note: it is the synthesis of facet values which together determine the value space and properties of the datatype. Please clarify

The enumerated values must be from the value space of A.

Asir S Vedamuthu <asirv@webmethods.com> to <w3c-xml-schema-ig@w3.org> and others, (date?)

Item 1

AM: Integer is derived from decimal by setting scale=0 The PSV infoset for derived datatypes indicates all the facets of the base datatype and their fixed values

If so, integer datatype has -

Item 2

AM: The number of days in the month or year will depend on when the period occurs. We take the position that this is always known and, thus, there is no ambiguity but would like to see counterexamples. ISO8601 seconf edition, does say in 3.15 that "in certain applications a month is regarded as a unit of time of 30 days".

However, 'period' is not a facet or constraining facet of timeDuration. Need more clarification.

Item 3, 4 & 5

Cool. Then item 3, 4 & 5 call for editorial corrections to Part 2 Datatypes spec.

Ashok Malhotra to w3c-xml-schema-ig-request@w3.org, Thursday, May 04, 2000 10:42 AM

[The number of days will depend on when the period occurs; this should always be known, no? If you have another use case, it would be useful to see it.]

Asir S Vedamuthu [mailto:asirv@webmethods.com] to petsa@us.ibm.com, Thursday, May 04, 2000 2:19 PM

Here is a simple use case -

&

"Ninggang Chen" <nchen@webMethods.com> to XML Schema Comments list on Thu, 11 May 2000 11:26:34 -0400

According to ISO 8601, there are four ways to express a period of time. The timeDuration datatype uses the second way, which is expressed "in one or more specific components but not associated with any specific start or end". ([ISO 8601] section 5.5.1)

There is no facet in timeDuration specifying the starting point of the time period and as we can see from Asir's example that the starting point is not necessarily known. Therefore, I have a impression that the definition of timeDuration is incomplete. If we don't have an unambiguous definition of year and month, this data type is simply not usable.

"Tim Berners-Lee" <timbl@w3.org> to XML Schema Comments list on Thu, 11 May 2000 16:07:19 -0400

Comments on xml-schemas

Firstly, It is essential that important things be referenceable by URI. It is much easier and safer to use a barenames #id xpointer reference than a complex xpointer expression. Given that HTML element name and complex types are really important concepts in a schema, and ones which people will want to refer to from other languages and other schemas, please use type IDs for that. (I note that unfortunately this cannot apply to attributes: the creators of schemas will have to think of [an] appropriate ID and give it explicitly if they want others to be able to use a barename reference to refer to the attribute name.) It is I think worth forcing complex types and element names to share the same space, because little is lost (except for some confusion!) and one gains the power of xml ID and barename xpointer references for both.

Secondly, I note that the schema spec used name= for element types instead of the more natural id="". I made that mistake a long time ago with HTML <A name=> ... and it has been a thorn in everyone's side ever since! Please do not make that mistake again!!!! Specs should use id= for things of type ID. (I would be in favor of reserving and predefining it in all namespaces myself, as it would allow an xpointer reference to be followed without having to look up the DTD or schema, and I feel that without that XML becomes unbearably complex)

The same applies to data types. If schema foo defines a datatype bar then it really is too clumsy unless foo#bar is the datatype's URI.

"Ralph R. Swick" <swick@w3.org> to XML Schema Comments list on Thu, 11 May 2000 16:23:33 -0400

The xsd:appinfo schema component in the schema-for-schemas http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/#element-appinfo appears to adequately address the request for a mechanism to permit an XML Schema schema document to hold declarations for mapping to other application data structures documented in item 3.2 of http://www.w3.org/TR/1999/NOTE-schema-arch-19991007.

I thank the XML Schema WG for including this feature. I also commend the WG for illustrating one usage scenario in the Schema for Datatype definitions http://www.w3.org/TR/2000/WD-xmlschema-2-20000407/#schema

My enthusiasm is tempered, however, by the lack of any guidance on how to discover the semantics of the two example elements has-facet and has-property. Having constructed all this wonderful machinery for extending the declarative power of an XML Schema, the sole example of its use fails to lead the way in applying that same machinery to the extension. has-facet and has-property do not themselves have first-class names, nor are they even clearly part of a namespace. I encourage the spec editors to lead by example in your application of appinfo.

"Arnold, Curt" <Curt.Arnold@hyprotech.com> to XML Schema Comments list on Thu, 11 May 2000 15:43:15 -0600

The narrative and schema for schemas allow groups to contain annotation, group, and any elements as children. The DTD only allows all, choice and sequence.

Jane Hunter <jane@dstc.edu.au> to XML Schema Comments list on Fri, 12 May 2000 11:31:17 +1000

Here's MPEG-7's feedback to the current XML Schema Language WDs: http://archive.dstc.edu.au/mpeg7-ddl/issues.html

It's based on problems which have arisen during encodings of MPEG-7 Descriptors and Description Schemes. Examples of these can be found at: http://archive.dstc.edu.au/mpeg7-ddl/

In some cases there may be alternative methods for solving a problem, so we'd appreciate suggestions from the WG.

I'm going to be at WWW9 in Amsterdam next week so I'll be available to discuss any of these issues face-to-face then if any of the WG are interested.

David RR Webber <Gnosis_@compuserve.com> to XML Schema Comments list on Fri, 12 May 2000 03:16:54 -0400

Group.

I'm reporting here direct from the lobby of the ebXML meeting in Brussels.

Some significant decisions have been made this week, and it is very clear that ebXML is one of the major potential users of XML Schema.

It is also clear that several of the potentially mission critical features required are either missing (support for ISO11179 datatypes) or unclearly defined in the current Schema draft.

Also - ebXML is very focused on providing sustainable and low-cost business solutions that are scalable to a global level.

Looking at this there are just too many issues with the current W3C Schema draft to make it viable.

Simply put - if I were asked today by an MIS Manager if I would recommend W3C Schema in its current form as the basis for a major new implementation I would emphatically have to say - NO.

I would there ask that the current period for the review of this release candidate be extended at least another 4 weeks to allow time for discussion of the issues relating specifically to support of the ebXML requirements, and that we develop a set of metrics that we can measure the suitability-to-task in the context of maintainability and use in a global eBusiness environment.

I will work on a draft of these today and post these tonight when I get back to the USA.

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list on 12 May 2000 10:21:11 +0100

Currently this is as follows:

where 'particle' is

I'd like to change this to

where 'explicitGroup' is

I think the defaulting of the wrapper is messy, confusing and is getting in our way: the increased clarity in requiring a single <all>, <choice> or <sequence> outweighs the extra verbosity.

The one potential problem is that people will have to learn to write e.g.

for backward-compatible mixed content.

To: www-xml-schema-comments@w3.org From: ht@cogsci.ed.ac.uk (Henry S. Thompson) Date: 12 May 2000 10:24:21 +0100 Message-ID: <f5bsnvoi0je.fsf@cogsci.ed.ac.uk> Subject: Error logging in the infoset

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list on 12 May 2000 10:24:21 +0100

Pursuant to our decision in Berkeley to allow the editors the option to systematise and tabulate 'errors', the next internal draft will contain a table of ways to lose and explicit short identifiers for all of them. I'd like to add a post-schema-validation infoset property associated with element and attribute infoitems which records these when appropriate.

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list on 12 May 2000 10:40:26 +0100

Someone recently observed to me that we don't explicitly rule out circular type definition. We certainly should, but I wonder if we should consider a carefully controlled exception to this, and to the no redefinition/redeclaration rule: You can redefine or redeclare imported or included components inside the include/import element, and only there. Furthermore, such redefinitions may be circular in the case of types, named model groups and attribute groups, and all such redefinitions are retrospective, i.e. they effect the included/imported components which reference those definitions.

Simple example

schema1.xsd

schema2.xsd

Documents using schema2 for the http:///www.example.com/stuff would be able to have <genMark> as a daughter of <person> in their <record>s, whereas those using schema1 would not.

I certainly haven't thought through all the ramifications of this, but if we want to do anything at all to allow ourselves to reuse our own work, this is the best thing I've thought of.

Susan Lesch <lesch@w3.org> to XML Schema Comments list on Fri, 12 May 2000 03:15:32 -0800

These are a few possible minor typos in your Last Call draft, XML Schema Part 2: Datatypes "work in progress." A section number is followed by a quote and then a suggestion.

In section 3, there are 17 occurrences of double spaces under various "Derived datatypes," for example, in 3.2.1.2. You could remove the &nbsp;'s or put the pair of terms on one line. <a href="#dt-built-in">built-in</a>  <a href="#dt-derived">derived</a>

Status of this document - last par. recommendation [twice] → Recommendation

2.1 c) a set of facets [You might link to facet's definition the first time it is mentioned.]

2.4.1.4 par. 2 cardinality, there are → cardinality; there are [or] → cardinality. There are

2.4.1.12 par. 2 octect → octet

3.2 par. 1 derived from this the datatype → derived from this datatype

3.2.7 par. 2 ocurrence → occurrence

3.3.4.2 has an empty list item.

3.3.5 par. 1 fininte-length → finite-length

3.3.6 The value space of Name the set → The value space of Name is the set

3.3.8.1 a lexical consisting of → a lexical representation consisting of

3.3.15 This results in is the → This results in the

3.3.24.1, 3.3.25.1, 3.3.26.1, and 3.3.27.1 and an preceding "-" → and a preceding "-"

4. par. 1 present, optional → present; optional

4.2.12 note associated encoding. → associated with encoding.

5.1 table {variety} or any of its any ancestor [Sorry I didn't understand that phrase.]

5.1.2 par. 1 dataype → datatype

5.2 par. 1 specificing [Not sure. Do you mean specifying?]

5.2.10 example and only allow whole cents. → and only allows whole cents. [assuming "application" is the subject of the sentence]

5.2.12 par. 1 is a encoding → is an encoding

5.2.13 example Is "HMO" (Health Maintenance Organization) an internationally understood acronym? If not you might say "health insurance company."

A. and B. line 6 need closing parentheses followed by an ending period after "just in case". To be a little more formal, you could end the sentence after "entity expansions)."

A. lines 28 and 30 builtin → built-in

B. line 26 Customisation → Customization

E. note after table 3 it it logicall → it is logically

E.1 par. 11 chacters → characters

E.1.1 par. 4 and par. 8 compliment → complement

E.1.1 par. 8 Suppliment → Supplement

"Roger L. Costello" <costello@mitre.org> to XML Schema Comments list on Fri, 12 May 2000 08:51:46 -0400

The below comments summarize the points made in our white paper: <http://www.xfront.org/EvolvableSchemas.html>

Please read the white paper to obtain the full context of the comments.

Dan Rupe <Dan_Rupe@go.com> to XML Schema Comments list on Fri, 12 May 2000 08:21:18 -0700 (PDT)

I would like to be able to specify the opposite of <sequence> (unsequential) within complexTypes and groups.

Consider the following example in a schema:

In my instance document, I would simply like <C> to be able to come before <B>, for example.

Or, in this example schema snippet:

I would like to able to specify that any number of <B>'s and <C>'s can appear any number of times and in any order. Like this:

It's my understanding that the order of elements declared within a complexType in the schema must appear in that same order in the instance document. (Of course a minOccurs with a value of zero can make an element optional, but following elements must still appear sequentially in the instance document.) The Primer also mentions that a named group is <sequence> by default.

It seems the <all> element may be an attempt to provide unsequential capabilities, but I'm not sure if this is what <all> really provides. (I can't really tell for sure because XML Spy has not implemented it yet. Are there other validators out there that have?) If it does, it's use seems limited since it can only be used at the top-level of any content model, and the its children must be simple elements, not contained groups.

Since <sequence> is the default behavior of complex types and groups, I suggest one of two possible scenarios:

"Ralph R. Swick" <swick@w3.org> to XML Schema Comments list on Fri, 12 May 2000 13:01:09 -0400

The comments in Schema Structures, Section 4.2.1, regarding the use of xpointer to identify schema components do not go quite far enough to permit broad reuse of important features defined by XML Schema. http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/#section-References-to-Schema-Components-from-Elsewhere

Specifically, after lengthy discussion and deliberation the RDF Schema WG was persuaded to defer all base datatyping specifications until after an XML Schema specification was completed so as to be able to leverage any base datatypes from XML.

It will be a significant benefit to the wider XML application community if canonical URIs were defined for each of the built-in datatypes as well as for each the specified facets.

This request is certainly a subset of the broader request for an algorithm to derive a full URI for every Schema component from the namespace URI and the local name (and, perhaps the type or symbol space). I want to emphasize that even if the general case remains unaddressed in version 1, it is important and useful to address the specific case of the built-in datatypes. This partially addresses bullet 3.9 of http://www.w3.org/TR/1999/NOTE-schema-arch-19991007.

"Perry A. Caro" <caro@Adobe.COM> to XML Schema Comments list on Fri, 12 May 2000 12:12:08 -0700

It will be a significant benefit to the wider XML application community if canonical URIs were defined for each of the built-in datatypes as well as for each the specified facets.

Hear, hear! We emphatically agree with this request. Lack of reliable URI "id's" for the built-in datatypes and specified facets would be a huge obstacle to wide adoption and interoperability. This cannot be overstated.

It will be hard enough to implement compliant, interoperable, real-world processors--human error and the variety of character and URI encodings being what they are--without also having to worry about how to disambiguate the names of these vital items. That being the case, also consider:

To be sure, these last two items are mere wishes compared to the overriding requirement for canonical URI's of any shape or form to be part of the normative matter of the spec.

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list on 13 May 2000 10:24:58 +0100

In principle, which would you prefer:

"Ralph R. Swick" <swick@w3.org> to XML Schema Comments list on Fri, 12 May 2000 16:30:53 -0400

The control over namespace qualification provided by form and elementFormDefault appear, if I understand them correctly, to change default namespace processing in a very fundamental way. http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/#declare-element

It appears that the default case, 'elementFormDefault="unqualified"' would change what a processor currently understands to be the namespace of some unqualified elements within the scope of some parents. To understand which unqualified elements are bound to which namespaces requires schema processing.

This seems to make default namespace declarations unuseable, (or, conversely, to make schema processing a requirement rather than an option). Neither conclusion feels good to me. I hope I'm fundamentally misunderstanding, Schema Structures section 4.3.2 and that the statement in the final paragraph of Schema Primer section 3.1 is inaccurate. http://www.w3.org/TR/2000/WD-xmlschema-0-20000407/#UnqualLocals

Noah_Mendelsohn@lotus.com to XML Schema Comments list on Fri, 12 May 2000 17:16:15 -0400

I understand your confusion, but I think you have misinterpreted the schema specification. The namespace qualification or lack thereof for any element in a document to be validated is established according to the rules of the Namespaces Recommendation, and does not change during the course of schema validation. Indeed, validation is defined as an operation on an infoset, so all the mechanisms of namespace defaults and so on are applied before schema validation begins.

I think your confusion is about the case where we have an instance document that looks like this:

First of all, neither XML 1.0 nor namespaces itself introduces any notion of local scoping for elements. Therefore, it is not surprising that we cannot tell whether the declaration for <b> is locally scoped. Whether you use qualified or unqualified forms, local scoping is always an artifact of schema processing, never fundamental to the instance.

Furthermore, and I think this is your point of confusion, even if the declaration for <b> is locally scoped within the declaration for <n:a>, <b> itself is still not considered to be in a namespace. We cannot change that; the namespaces recommendation says it is not. So, the namespace URI in the infoset for the element (or lack of namespace URI in this case) is not changed by validation. What does happen as a result of the validation is that additional information is added to the infoset, and from that information you can make some determination as to the actual declaration for <b>. So, it is not <b> itself which appears in a namespace, but <b> is associated during validation with definitions and declarations which may well be in the target namespace "uria".

Note too that there is a direct analogy to the treatment of attributes per the namespaces recommendation: the typical attribute appears unqualified, but has a definition scoped to a possibly namespace qualified element on which it appears (you know it is scoped that way because two attributes named 'atr' appearing on two different elements in the same namespace can have two different default values. I don't think anyone disputes this. The namespaces recommendation makes clear that such unprefixed attributes are not specifically in the namespace of the element on which they appear, although a non-normative concept of namespace partition is discussed. Indeed, this analogy is often cited by proponents of 'elementFormDefault=qualified'.)

Now, having prepared this glib explanation, I will admit to one point of discomfort on my part. I had expected that we had put into the augmented infoset a contribution indicating the element declaration for <b>, from which you could surely determine its local scoping. I am a little surprised to see that we only supply the type, which in the example above may be something as simple as integer.

Note that this entire discussion has a direct analogy in the case where 'elementFormDefault="qualified"'. You still do not know whether the element is locally scoped until you check the schema, and namespaces are still assigned exactly according to the rules of the namespaces recommendation.

So, I think the fundamental design is sound. I would like to hear from other members of the schema workgroup whether we actually have the infoset contribution quite right. Henry?

Noah_Mendelsohn@lotus.com to XML Schema Comments list on Fri, 12 May 2000 17:27:59 -0400

Indeed, this analogy is often cited by proponents of 'elementFormDefault=qualified'.

Ooops. Of course I meant:

Indeed, this analogy is often cited by proponents of 'elementFormDefault=unqualified'.

Steven Goldfarb <Steven.Goldfarb@cern.ch> to XML Schema Comments list on Fri, 12 May 2000 14:17:02 -0700

We would like to request a modification to the current working draft of the XML Schema, Working Draft 7 April 2000. Specifically, we are interested in the implementation of a mechanism for the usage of symbolic constants in XML Schema.

Efforts have recently begun in the High Energy Physics community to use XML to describe the geometry of our detectors. Several languages have already been developed toward this aim and we have recently begun work toward merging our efforts into a standard.

Our geometrical description of a detector involves the construction of a complex structure from simple components in an iterative manner. We create elementary solids and position instances of them in space. These actions require the entry of explicit values for the dimensions of the solids and the coordinates of the positions. In our current model, we store these values as attributes. This involves the entry of thousands of values to describe these complex detectors, making it essential to avoid data repetition.

Ideally, we would like to be able to define a symbolic constant in the XML implementation which could be referenced throughout the document. The constant therefore needs to have a type, a name, a value and possibly a unit. In our case, we would include the constant as an attribute or as element content. Most likely, this implies the need for a mechanism to differentiate between a symbol and plain text when referencing.

To give an example for the XML implementation, we would like to be able to describe a piece of geometry like:

In this example, the parser would replace the name of the symbol with the value of the symbol. It is important that this also support type checking, i.e. in the example above, the attributes X, Y and Z should all be defined as 'double'.

We realise that this feature is not implemented for XML and we hope that this will be revised in the future. However, XML schema could benefit from this by facilitating the creation of default values. In the current XML Schema working draft, the default values must be typed explicitly, and cannot be a reference to a previously defined constant.

During the course of our discussions with other experts we found that the 'Express' language contains a similar mechanism to handle symbolic constants, as well as being able to use arithmetic expresssions. Clearly, also this community would benefit from our request.

"Ninggang Chen" <nchen@webMethods.com> to XML Schema Comments list on Fri, 12 May 2000 17:38:17 -0400

In the schema spec, it says "1.2.4 If the {content type} is element-only or mixed, the sequence of the element information item's element information item [children], if any, taken in order, is schema-valid with respect to the {content type}'s particle, as defined in Element Sequence Valid (Particle) (§3.8)" ( http://www.w3.org/TR/xmlschema-1/#Complex_Type_Definition_details).

So how do we represent <!ELEMENT P (#PCDATA|a|b|c)> in schema?! The order and number of child elements are not constrained in XML 1.0, and therefore many industry users have already used this model in their documents. How can they easily migrate these documents to schema? Or should we suggest them using DTDs for old documents but using schema when create new documents?

Dan Connolly <connolly@w3.org> to XML Schema Comments list on Fri, 12 May 2000 17:25:03 -0500

nchen wrote: ... So how do we represent <!ELEMENT P (#PCDATA|a|b|c)> in schema?! The order and number of child elements are not constrained in XML 1.0

I believe you are mistaken. That syntax is not legal in XML 1.0. There is a similar syntax that has the property that the order and number of children are not constrained:

(note the *).

This has a straightforward analog in XML Schema:

Jim Trezzo <jtrezzo@us.oracle.com> to XML Schema Comments list on Fri, 12 May 2000 16:03:28 -0700

Oracle Comments on XML Schema Last Call:

Here are the comments we have collected within Oracle.

David Beech and Jim Trezzo

Philip Wadler <wadler@research.bell-labs.com> to XML Schema Comments list on Fri, 12 May 2000 19:08:51 -0400

Simplifying XML Schema

The current Schema proposal is complex. Programmers have shown a remarkable ability to put up with complexity, but we do not yet know whether the XML community will be so forgiving. We would like to suggest that it is possible to greatly simplify XML Schema, while not unduly limiting its power. Indeed, some of the suggestions below would both simplify Schema and extend its power at the same time.

We are also asking the XML Query working group to support changes along these lines, but in writing this letter we are not acting as representatives of XML Query.

Yours sincerely,

Philip Wadler, Lucent

Jerome Simeon, Lucent

Mary Fernandez, AT&T

Don Brutzman <brutzman@nps.navy.mil> to XML Schema Comments list on Fri, 12 May 2000 20:35:59 -0700

The following comments are based on document review and known DTD shortfalls. We have only done preliminary examinations of schema instantiations for the X3D tagset. Summary: looks good.

References:

1. The Extensible 3D (X3D) specification makes heavy use of float, double and integer lists. The list support for float/double/integer appears useful and usable.

2. X3D lists of floats/doubles/integers are often lists of 2-tuples, 3-tuples or 4-tuples. Such typing is commonplace for 3D graphics (e.g. translations are 3-tuples, orientations are axis-angle 4-tuples). Regular-expression patterns will let us express these relationships (hopefully without redefining the numeric base types, not yet sure). No draft schema appears in the current SVG draft - pertinent examples are welcome.

A helpful facet might be to specify the tuple-ordinality of a list type, so that only appropriate multiples of the typed data are allowed. Please be aware that wrapping such X3D tuples in their own type tags has been considered, but is impractical due to unneccesary redundancy and the extremely large volumes of numeric data involved in many scenes.

...

4. Thanks for this excellent work. If further issues are identified during eventual production of the X3D schema, we'll report them back.

Don Brutzman <brutzman@nps.navy.mil> to XML Schema Comments list on Fri, 12 May 2000 20:35:59 -0700

3. A further feature X3D might use is the ability to identify & evaluate further numerical constraints to be placed on data. For example, Normal (i.e. perpendicular vector) 3-tuples should have unit magnitude. It appears language-specific data validation will be needed to check such cases, probably corresponding to named simpleType or complexType definitions. So Schema capabilities at least appear sufficient to enable such checking independently, even if not supporting it directly.

4. Thanks for this excellent work. If further issues are identified during eventual production of the X3D schema, we'll report them back.

"gmacri@libero.it"<gmacri@libero.it> to XML Schema Comments list on Sun, 14 May 2000 16:11:28 +0200

When I write a XML schema as this that follow:

the group's "ref" attribute must always refer to a group that is child (top level) of schema ?

ht@cogsci.ed.ac.uk (Henry S. Thompson) to XML Schema Comments list on 14 May 2000 20:57:40 +0100

"gmacri@libero.it"<gmacri@libero.it> writes:

the group's "ref" attribute must always refer to a group that is child (top level) of schema ?

Yes.

In general (except for local element and attribute declarations, that is), named things must occur at the top level.

Without exception, only things named at the top level can be 'ref'ed.

2. Extensibility Issue

MPEG-7 requires clarification of:

Murray Altheim, Review of XML Schema Specification, 11 May 2000

Part 1 : Structures

§2.2.6 Annotation Components

While it certainly makes sense that the Schema spec would not define the annotation mechanism, I would have hoped that the DTD design (and the Schema for Schemas) would make it easy to extend. Perhaps rather than (from part2.dtd):

this could be declared as:

although I'm not sure how I'd modify the DTD or Schema for Schemas if I wanted to say, insert a <xhtml:div> here.

3. Parameterization of Array and Matrix Sizes

We would like to define the size of lists (arrays and matrices) at the time of instantiation. In the example below we suggest a valuePar construct which gives the name of the attribute whose value will be used for the facet. The attribute data type must match the facet data type. This example is currently problematic because facets only apply to simple types and attributes can only be added to complex types. The other issue is whether VectorI is being restricted or extended?

Don Brutzman <brutzman@nps.navy.mil> to XML Schema Comments list on Fri, 12 May 2000 20:35:59 -0700

2. X3D lists of floats/doubles/integers are often lists of 2-tuples, 3-tuples or 4-tuples. Such typing is commonplace for 3D graphics (e.g. translations are 3-tuples, orientations are axis-angle 4-tuples). Regular-expression patterns will let us express these relationships (hopefully without redefining the numeric base types, not yet sure). No draft schema appears in the current SVG draft - pertinent examples are welcome.

A helpful facet might be to specify the tuple-ordinality of a list type, so that only appropriate multiples of the typed data are allowed. Please be aware that wrapping such X3D tuples in their own type tags has been considered, but is impractical due to unneccesary redundancy and the extremely large volumes of numeric data involved in many scenes.

4. Typed References

MPEG-7 requires 'typed references' or the ability to constrain IDs and IDREFs to particular elements:

5. Derivation Issues

...

5.2 Combined Restriction and Extension in One Step

The current XML Schema WD allows a new complex type to be derived from an existing one either by restriction or extension but not both at the same time. Nevertheless, it is quite common for a new type to both restrict and extend a base type. The constraint imposed by the current XML Schema WD means that such type derivation has to go through two steps: a restriction followed by an extension or vice versa. This will create a large number of dummy types. For example:

We then define "D" which restricts B to a single occurrence and adds a new element E. We would like to do this in one step (not two):

5.3 Unambiguous derivation of nested elements

If we allow derivation by both restriction and extension in a single step then there needs to be a mechanism for specifying the exact path of element derivations. This is required to avoid ambiguity when there are anonymous embedded type definitions. For example:

Is "C" an extension (that is, a new element) or a restriction of "B.C"? If the latter, then it would be better to use a path specification such as B.C. :

5.4 Derivation by Restriction/Extension using Derived Complex Type

We would like to be able to do the following kinds of derivation by restriction/extension based on an existing restricted/extended complex type:

6. Inconsistencies in Occurrence Constraints In the current working draft there are inconsistencies between the specification of occurrence constraints for elements and attributes e.g. default="37" vs. use="default" value="37". It would be much better if the same attributes are used.

Paul Cotton <paulcotton@alumni.uwaterloo.ca> to www-xml-schema-comments@w3.org, Mon, 29 May 2000 12:28:34 -0400, Subject: XML Query Comments to XML Schema (2nd part)

2.4 Problems with minoccurs and maxoccurs

A. The default for maxOccurs behaves counter-intuitively. When maxOccurs is not explicitly specified, it inherits the value of minOccurs (which defaults to 1 if not specified). This is confusing. For example, po.xsd in XML-Schema Part-0 (Primer) contains the declaration <xsd:element ref="comment" minOccurs="0"/>

This effectively prohibits comments in the instance-document.

The XML Query Working Group suggests that Schema require that minOccurs and maxOccurs occur together or that Schema normatively adopt the default-rule mentioned in Appendix B of XML Schema Part-1: "maxOccurs defaults to 1 or minOccurs, whichever is greater".

B. The XML Query Working finds the different treatment of the properties minOccurs/maxOccurs, fixed, default, and value in the XML representation for element-declarations and for attribute-declarations confusing. The XML Query Working group suggests to use the same representation for element-declarations and attribute-declarations, and constrain the allowed value for minOccurs and maxOccurs in attribute-declarations to "0" or "1". This would allow queries such as:

to be evaluated more efficiently.

C. There is an inconsistency between '*' and 'unbounded'. Primer uses "*" to mean Infinity; Data Type spec uses "*" in appendix B. Other places in the spec use "unbounded".

7. Element-specific Importation and Exportation It would be useful to be able to specify the importation of specific individual elements, types, attributes or groups rather than only complete schemas.

We would also like to be able to specify which particular components (elements, types, attributes, groups etc.) of a schema are exportable.

"Roger L. Costello" <costello@mitre.org> to XML Schema Comments list on Fri, 12 May 2000 08:51:46 -0400

[1] Please reinstate the capability to specify open content using an attribute (i.e., content = "open").

Rationale:

Murray Altheim, Review of XML Schema Specification, 11 May 2000

Part 1 : Structures

§2.2.1.3 Complex Type Definition

The failure of complex type definitions to allow only appending extensions seems very limiting. In a DTD might see a content model defined as:

It sounds as if it would be impossible to extend this to:

Being able to extend by appending particles after backmatter is pretty useless in this context. It seems that this would require a schema author to resort to redefinition rather than extension, thus losing any advantages of type inheritance.

"Roger L. Costello" <costello@mitre.org> to XML Schema Comments list on Fri, 12 May 2000 08:51:46 -0400

[2] Please make the schema for schemas open.

Rationale:

"Roger L. Costello" <costello@mitre.org> to XML Schema Comments list on Fri, 12 May 2000 08:51:46 -0400

[3] Please define the expected behavior of an application configured to process (e.g., extract data from) documents conforming to schema 'X' when it receives documents conforming to schemas derived from schema 'X'.

"Roger L. Costello" <costello@mitre.org> to XML Schema Comments list on Fri, 12 May 2000 08:51:46 -0400

[4] Simplify the schema by making it open and moving the more complex features to a non-binding portion of the schema spec. The resulting simplified version of the XML Schema spec can then gradually evolve to incorporate the more complex features (if the market dictates).

Jim Trezzo <jtrezzo@us.oracle.com> to XML Schema Comments list on Fri, 12 May 2000 16:03:28 -0700

Part 1: Structures

1. Identity-constraint table

For reasons of performance, and avoidance of duplicate implementation, we believe that a conforming schema processor should always be prepared to pass the results of its keyref checking in the PSV-infoset. It could be very expensive for applications such as query processors to have to redo this work, both in run-time performan