XML Schema: Last-Call Issues

(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

• <or>: The <or> facet is satisfied if any of the contained facets is satisified.
• <and>: The <and> facet is satisified if all of the contained facets are satisifed.
• <nor>: The <nor> facet is satified if none of the contained facets are satisified. A <nor> with a single contained facet is used to perform a not operation.
• <conform>: The conform facet is satified if the lexical representation would be acceptible to the specified datatype.
• <enumeration>: For this to work right, <enumeration> needs to become a container of <literal> elements which will make it logically equivalent to all the other facets.

Examples:

<simpleType name="maxOccur" base="string">
    <or>
        <conform type="non-negative-integer"/>
        <enumeration><literal value="*"/></enumeration>
    </or>
</simpleType>

<simpleType name="noTeens" base="integer">
    <or>
        <and>
            <minInclusive value="0"/>
            <maxExclusive value="10"/>
        </and>
        <minInclusive value="20"/>
    </or>
</simpleType>

<simpleType name="targetOrNamespace" base="string">
    <or>
        <enumeration>
            <literal value="##targetNamespace"/>
        </enumeration>
        <conform type="uri-reference"/>
    </or>
</simpleType>

<simpleType name="targetOrNamespaces" 
            base="targetOrNamespace" 
            derivedBy="list"/>

<simpleType name="anyAttribute" base="string">
    <or>
        <enumeration>
            <literal value="##any"/>
            <literal value="##other"/>
            <literal value="##local"/>
        </enumeration>
        <conform type="targetOrNamespaces"/>
    </or>
</simpleType>

(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:

• is: denotes the namespace for information set items
• psvis: denotes the namespace for Schema contributions to Infoset

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

<!ELEMENT psvis:identityConstraintTable 
          (psvis:identityConstraint, psvis:nodeTable)*> 
<!ELEMENT psvis:identityConstraint is:ref>
<!ELEMENT psvis:nodeTable (psvis:keySequence, psv:qualifiedNode)*>
<!ELEMENT psvis:keySequence (is:ref)*> 
<!ELEMENT psvis:qualifiedNode is:ref>
<!ELEMENT is:ref EMPTY> 
<!ATTLIST is:ref idref > 

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:

fun nodeTable(E, C) {
  let /* compute node table for element E & constraint C */

      table = UNION(forall (keyseq, qualnode) in eligibleConstraint(E,C))
      /* inherit non-conflicting constraints from children */
      kidsTable  = UNION(forall K in children(E), nodeTable(K, C))
      inheritTable = kidsTable - table
  in table UNION inheritTable
}
// inheritTable is really a project on key-sequence, difference of the
// two tables and then a join with kidsTable to reconstruct the
// inherited table.

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)

<purchaseReport>
  <regions>
    <zip code="95819"> 
      <part number="872-AA"/> 
      <part number="455-BX"/>  
   </zip>
    <zip code="63143"> 
      <part number="455-BX"/> 
   </zip>
 </regions>
  <parts>
    <part number="872-AA">Lawnmower</part>  
    <part number="455-BX">Sturdy Shelves</part> 
  </parts>
</purchaseReport>

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

<is:Document id="document#0">
  <is:children>
    <is:ref idref="element#0"/>
    <!-- reference to infoset item for schema -->
    <psvis:schema idref="schema#0"/>
  </is:children>
</is:Document>

<is:Element is:id="element#0">
  <is:localName>purchaseReport</is:localName>
  <is:children>
    <is:ref idref="element#1">
    <is:ref idref="element#7">
  </is:children>

  <psvis:identityConstraintTable>
    <!-- Skip <unique> constraint -->
    <!-- Constraint : <key name="pNumKey">  --> 
    <psvis:identityConstraint>
      <!-- reference to infoset item for 
       <key name="pNumKey"> -->
      <is:ref idref="identityConstraint#0"/>
    </psvis:identityConstraint>
    <psvis:nodeTable>
      <psvis:keySequence>
        <!-- number="872-AAA" -->
        <is:ref idref="attribute#5"/>
      </psvis:keySequence>
      <psvis:qualifiedNode>
        <is:ref idref="element#8"/>
      </psvis:qualifiedNode>

      <psvis:keySequence>
        <!-- number="455-BX" -->
        <is:ref idref="attribute#6"/>
      </psvis:keySequence>
      <psvis:qualifiedNode>
        <is:ref idref="element#9"/
      </psvis:qualifiedNode>
    </psvis:nodeTable>

    <!-- Constarint : <keyref refer="pNumKey"> --> 
    <psvis:identityConstraint>
      <!-- reference to infoset item for
       <keyref refer="pNumKey">...</key> -->
      <is:ref idref="identityConstraint#1"/>
    </psvis:identityConstraint>
    <psvis:nodeTable>
      <psvis:keySequence>
        <!-- number="872-AAA" -->
        <is:ref idref="attribute#1"/>
      </psvis:keySequence>
      <psvis:qualifiedNode>
        <is:ref idref="element#8"/>
      </psvis:qualifiedNode>

      <psvis:keySequence>
        <!-- number="455-BX" -->
        <is:ref idref="attribute#2"/>
      </psvis:keySequence>
      <psvis:qualifiedNode>
        <is:ref idref="element#9"/
      </psvis:qualifiedNode>

      <psvis:keySequence>
        <!-- number="455-BX" -->
        <is:ref idref="attribute#4"/>
      </psvis:keySequence>
      <psvis:qualifiedNode>
        <is:ref idref="element#9"/
      </psvis:qualifiedNode>
    </psvis:nodeTable>
  </psvis:identityConstraintTable>
</is:Element>

<is:Element is:id="element#1">
  <is:localName>regions</is:localName>
  <is:children>
    <is:ref idref="element#2"/>
    <is:ref idref="element#5"/>
  </is:children>
</is:Element>

<is:Element is:id="element#2">
  <is:localName>zip</is:localName>
  <is:attributes>
    <is:ref idref="attribute#0"/>
  </is:attributes>
  <is:children>
    <is:ref idref="element#3"/>
    <is:ref idref="element#4"/>
  </is:children>
</is:Element>

<is:Element is:id="element#3">
  <is:localName>part</is:localName> 
  <is:attributes>
    <is:ref idref="attribute#1/>
  </is:attributes>
</is:Element>

<is:Element is:id="element#4">
  <is:localName>part</is:localName> 
  <is:attributes>
    <is:ref idref="attribute#2/>
  </is:attributes>
</is:Element>

<is:Element is:id="element#5">
  <is:localName>zip</is:localName>
  <is:attributes>
    <is:ref idref="attribute#3"/>
  </is:attributes>
  <is:children>
    <is:ref idref="element#6"/>
  </is:children>
</is:Element>

<is:Element is:id="element#6">
  <is:localName>part</is:localName> 
  <is:attributes>
    <is:ref idref="attribute#4/>
  </is:attributes>
</is:Element>

<is:Element is:id="element#7">
  <is:localName>parts</is:localName> 
  <is:children>
    <is:ref idref="element#8"/>
    <is:ref idref="element#9"/>
  </is:children>
</is:Element>

<is:Element is:id="element#8">
  <is:localName>part</is:localName> 
  <is:attributes>
    <is:ref idref="attribute#5/>
  </is:attributes>
  <is:children>
    <!-- references to CDATAItems for "Lawnmower" -->
  </is:children>
</is:Element>

<is:Element is:id="element#9">
  <is:localName>part</is:localName> 
  <is:attributes>
    <is:ref idref="attribute#6/>
  </is:attributes>
  <is:children>
    <!-- references to CDATAItems for "Sturdy Shelves" -->
  </is:children>
</is:Element>

<is:Attribute is:id="attribute#0">
  <is:localName>code</is:localName>
  <value>95819</value>
</is:Attribute>

<is:Attribute is:id="attribute#1">
  <is:localName>number</is:localName>
  <value>872-AA</value>
</is:Attribute>

<is:Attribute is:id="attribute#2">
  <is:localName>number</is:localName>
  <value>455-BX</value>
</is:Attribute>

<is:Attribute is:id="attribute#3">
  <is:localName>number</is:localName>
  <value>872-AA</value>
</is:Attribute>

<is:Attribute is:id="attribute#4">
  <is:localName>number</is:localName>
  <value>455-BX</value>
</is:Attribute>

(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):

<par> 
 <video .../>
 <audio .../>
</par>

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:

<par>
<p>First Paragraph.</p>
<p>Second Paragraph.</p>
</par>

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:

<par>
<p begin="0s" dur="1s">First Paragraph.</p>
<p begin="2s" dur="1s">Second Paragraph.</p>
</par>

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

<anyAttribute namespace="##any" processContents="strict"/>

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

<html
 xmlns="http://www.w3.org/1999/xhtml"
 xmlns:xsi='http://www.w3.org/1999/XMLSchema-instance'
 xmlns:t='http://www.w3.org/2000/TR/smil-animation10'
 xsi:schemaLocation="http://www.w3.org/1999/xhtml html.xsd
         http://www.w3.org/2000/TR/smil-animation10 smil-animation.xsd
                "
  >
<head><title>Example of mixing HTML and SMIL timing</title></head>
<body><h1>Some stuff</h1>
<!-- example from 
http://www.w3.org/TR/NOTE-HTMLplusTIME -->

<p t:begin="1">
         This is a paragraph of text that appears after one second
     </p>
     <p t:begin="2">
         This is a paragraph of text that appears after two seconds
     </p>
     <p t:begin="3">
         This is a paragraph of text that appears after three seconds
     </p>

</body>
</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)

 <element name='p'>
  <complexType content='mixed'>
   <anyAttribute namespace="##other" processContents="strict"/>
    [...]
  </complexType>
 </element>

and in smil-animation.xsd :

   <attribute name='begin' type='string'/>
   <attribute name='dur' type='string'/>
   <attribute name='end' type='string'/>
   <attribute name='restart'>
    <simpleType base='string'>
     <enumeration value='always'/>
     <enumeration value='never'/>
     <enumeration value='whenNotActive'/>
    </simpleType>
   </attribute>
   <attribute name='repeatCount' type='string'/>
   <attribute name='repeatDur' type='string'/>
   <attribute name='fill'>
    <simpleType base='string'>
     <enumeration value='remove'/>
     <enumeration value='freeze'/>
    </simpleType>
   </attribute>

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:

<xsd:complexType content="mixed" name="aType">
	<xsd:attribute name="href" type="xsd:uriReference"/>
	...other linking attribute declarations
</xsd:complexType>

In the SMIL.xsd:

<xsd:attributeGroup name="smilTimingAttrs" />
	<xsd:attribute name="begin" type="xsd:string"/>
	<xsd:attribute name="end" type="xsd:string"/>
	...other timing attribute declarations
</xsd:attributeGroup>

And then in the XHTML+SMIL.xsd:

<xsd:element name="a" type="xhtml:aType">
	<xsd:attributeGroup ref="smilTimingAttrs"/>
</xsd:element> 

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.

<datatype base="string" name="XPath"/>

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:

<!-- For 'element' and 'attribute' -->
  <attributeGroup name="valueConstraint">
    <attribute name="default" type="string"/>
    <attribute name="fixed" type="string"/>
    <attribute name="initial" type="string"/>
  </attributeGroup>

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.

<element name="order">
  <attribute name="quantity" type="non-negative-integer" initial="1"/>
  <attribute name="item" type="uri-Reference"/> 
</order>

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

<order item="http://www.buyme.com/item.xml?5555"/>

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?

 
<extension>...</extension>
<statement>...</statement> 
<disclosure>...</disclosure>
<statement>...</statement> 
<extension>...</extension>
<statement>...</statement>

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:

regExp         ::= branch ('|' branch)*  >Regular Expression (branch|branch|...)
branch$        ::= piece+                >Branch (piece+)
piece$         ::= atom quantifier?      >Piece (atom quantifier?)
quantifier$    ::= [?*+] 
                 | ( '{' quantity '}' )  >Piece quantifier (? | * | + | {quantity})
quantity$      ::= quantRange 
                 | quantMin 
                 | QuantExact            >Numeric quantity

quantRange$    ::= QuantExact ',' QuantExact >Quantity range {n,m}

quantMin$      ::= QuantExact ','        >Minimum quantity {n,}
QuantExact$    ::= [0-9]+                >Exact quantity {n}
atom$          ::= Char 
                 | charClass 
                 | ( '(' regExp ')' )    >Atom (char | charclass | (regexp))
Char$          ::= [^.\?*+()|#x5B#x5D]   >Normal character (any non-metacharacter)
charClass      ::= charClassEsc 
                 | charClassExpr         >Character class (escape | expression)
charClassExpr$ ::= '[' charGroup ']'     >Character class expression ( [charGroup] )
charGroup      ::= negCharGroup 
                 | posCharGroup 
                 | charClassSub          >Character group
negCharGroup$  ::= '^' posCharGroup      >Negative character group
charClassSub$  ::= ( posCharGroup | negCharGroup ) '-' charClassExpr
                                         >Character class subtraction
posCharGroup$  ::= ( charRange | charClassEsc )+
                                         >Positive character group (character range | character class escape)+
charRange$     ::= seRange 
                 | XmlCharRef 
                 | XmlChar               >Character range (XML character|s-e range)
seRange$       ::= charOrEsc '-' charOrEsc
                                         >s-e character range
charOrEsc$     ::= XmlChar 
                 | SingleCharEsc         >XML character or single-character escape
XmlChar$       ::= [^\#x2D#x5B#x5D]      >XML character (all except \[])
XmlCharRef     ::= ('&#' [0-9]+ ';') 
                 | ('&#x' [0-9a-fA-F]+ ';')
                                         >Character-Reference (Ù or ê)
charClassEsc   ::= ( SingleCharEsc | MultiCharEsc | catEsc | complEsc )
                                         >Character class escape
SingleCharEsc  ::= '\' [nrt\.?*+()|{}#x2D#x5B#x5D#x5E]
                                         >Single character escape
MultiCharEsc   ::= '.' 
                 | ('\' [sSiIcCdDwW])    >Multi-character escape
catEsc$        ::= '\p{' charProp '}'    >Category escape
complEsc$      ::= '\P{' charProp '}'    >Category escape compliment
charProp$      ::= Letters 
                 | Marks 
                 | Numbers 
                 | Punctuation 
                 | Separators 
                 | Symbols 
                 | Other 
                 | IsBlock          >Unicode character property
IsBlock        ::= 'Is' [a-zA-Z]+   >Unicode block name
Letters        ::= 'L' [ultmo]?     >Unicode letters category
Marks          ::= 'M' [nce]?       >Unicode marks category
Numbers        ::= 'N' [dlo]?       >Unicode numbers category
Punctuation    ::= 'P' [cdseifo]?   >Unicode punctuation category
Separators     ::= 'Z' [slp]?       >Unicode separators category
Symbols        ::= 'S' [mcko]?      >Unicode symbols category
Other          ::= 'C' [cfson]?     >Unicode other category

(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:

• '+' to '-', and '/'
• '+', and '-' to '/'

(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

<xsd:simpleType 
  name="italianDecimal" base="xsd:decimal" derivedBy="xsd:format">
  <xsd:locale value="IT-it" />
</xsd:simpleType>

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

<product partNumber="AS45">
  <description>Ink-jet Printer AS45</description>
  <price currency="EUR">1200.00</price>
</product>

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

<product partNumber="AS45">
  <description>Ink-jet Printer AS45</description>
  1200,00 EUR
</product>

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

<product partNumber="AS45">
  <description>Ink-jet Printer AS45</description>
  <price currency="EUR" xsi:locale="IT-it">1200,00</price>
</product>

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:

<xsd:element name="price">
  <xsd:complexType base="xsd:decimal" derivedBy="xsd:extension"
localisable="true">
      <xsd:attribute name="currency" type="IsoCurrencyCodes" />
  </xsd:complexType>
</xsd:element>

("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:

• a) you integrate some kind of "final" method to fix constraining facets (e.g. the definition of recurringDay would use the period and duration facets with this "final" mechanism to explicitly forbid any further attempts at adding additional constraints through the same facets).
• b) if this seems to be too complicated, it would also possible to make the above mechanism mandatory for any kind of facet (e.g. once a derived type was generated by using any one facet, that facet cannot be used anymore to further derive from that derived type). This would, perhaps, result in some of the derived built-in types that are currently defined, to be redefined as primitive types, but would resolve all potential ambiguities arising from multiple use of the same facet for any sort of grandchildren-derived type.

"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:

<!ATTLIST element xmlns:x CDATA #IMPLIED>
<!-- keep this schema XML1.0 valid --> 

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:

<!ATTLIST element xmlns:x CDATA #FIXED
          "http://www.w3.org/XML/1998/namespace">
<!-- keep this schema XML1.0 valid -->

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

<regions>
  <zip code="95819">
...

while the schema says it should be

<regions>
  <zipcode code="...">
...

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

<complexType name="RegionsType">
  <element name="zipcode" ....

If I am reading this correctly, this should be

 <element name="zip" .... 

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 -

• abstract a la RELAX
• syntax neutral
• business functional - ebXML

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.

<element name="primaryCustomer" type="PrimaryCustomer" >
   <complexType name="PrimaryCustomer">
      <element ref="accountNumber" minOccurs = "0"/>
      ......

      <group name = "customerKey" >
         <sequence>
            <element ref="customerNumber"/>
            <element ref="customerSuffix"/>
         </sequence>
      </group>
   </complexType>

   <key name = "customerNumber" >
     <selector> customerKey/customerNumber </selector>
     <field> @name </field> 
   </key>

   <key name = "customerSuffix" >
     <selector> customerKey/customerSuffix </selector>
     <field> @name </field> 
   </key>
 </element>

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:

<xsd:element ref="comment" minOccurs="0"/>

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

<xsd:element ref="comment" minOccurs="0" />

means

<xsd:element ref="comment" minOccurs="0" maxOccurs="1" />

and not

<xsd:element ref="comment" minOccurs="0" maxOccurs="0" />

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:

<xsd:attribute name="Code" base="xsd:string">
 <xsd:simpleType name="CodeList" 
                 base="xsd:string" 
                 derivedBy="xsd:list"/>
</xsd:attribute>
<MyCodeList xsi:type="CodeList">AB1 CD2 EF3</MyCodeList> 

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:

<xs:schema xmlns='[URI:martinbryan]' targetNamespace='[URI:martinbryan]'
           xmlns:xs='http://www.w3.org/1999/XMLSchema'>
 <xs:simpleType name='CodeList' base='xs:string' derivedBy='list'/>

 <xs:element name='MyCodeList' type='CodeList'/>
</xs:schema>

<docroot xmlns='[URI:martinbryan]'>
 ...
 <MyCodeList>AB1 CD2 EF3</MyCodeList>
</docroot>

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:

<xs:schema xmlns='[URI:martinbryan]' 
           targetNamespace='[URI:martinbryan]'
           xmlns:xs='http://www.w3.org/1999/XMLSchema'>
 <xs:simpleType name='CodeList' 
                base='xs:string' 
                derivedBy='list'/>
 <xs:element name='MyContainer' content='textOnly'/>
</xs:schema>

<docroot xmlns='[URI:martinbryan]'
         xmlns:xsi='http://www.w3.org/1999/XMLSchema-instance'>
 ...
 <MyContainer xsi:type='CodeList'>AB1 CD2 EF3</MyCodeList>
</docroot>

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:

<xs:schema xmlns='[URI:martinbryan]' targetNamespace='[URI:martinbryan]'
           xmlns:xs='http://www.w3.org/1999/XMLSchema'>

 <xs:element name='MyContainer' content='textOnly'/>
</xs:schema>

<container xmlns='[URI:martinbryan]'
         xmlns:xsi='http://www.w3.org/1999/XMLSchema-instance'
         xmlns:xs='http://www.w3.org/1999/XMLSchema'
         xsi:schemaLocation='[URI:martinbryan] #xpointer(*/xs:schema)'>
 <xs:schema  targetNamespace='[URI:martinbryan]'>
  <include 'schema3.xsd'/>
  <xs:simpleType name='CodeList' base='xs:string' derivedBy='list'/>
 </xs:schema>
 <docroot>
   ...
   <MyContainer xsi:type='CodeList'>AB1 CD2 EF3</MyCodeList>
 </docroot>
</container>

"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:

 <xsd:attribute name="Code" base="xsd:string">
  <xsd:simpleType name="CodeList" base="xsd:string" derivedBy="xsd:list"/>
 </xsd:attribute>
 <MyCodeList xsi:type="CodeList">AB1 CD2 EF3</MyCodeList> 

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:

<banana Code='AB1 CD2 EF3'>...</banana>

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:

• 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?
• The attribute "BLOCK" used in the definition of some schema's component is equivalent to old attribute "EXACT" ?

[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

<xs:complexType name="length1" 
                base="dt:non-negative-integer"
                derivedBy="extension"/>
... 
...
<xs:element name="size" type="dt:non-positive-integer"/>

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:

    <complexType name='template' content='mixed'>
        <element ref='xsl:instruction' />
        <any namespace='##other' />
    </complexType>

    <complexType name='named-template' base='xsl:template-with-space' derivedBy='extension' >
        <element name='param' type='xsl:variable-definition'/>  <!--  should have a minOccurs/maxOccurs here -->
        <attribute name='match' type='xsl:pattern' />
        <attribute name='name' type='QName' />
        <attribute name='priority' type='xsl:XPathNumber' />
        <attribute name='mode' type='QName' />
    </complexType>

    <complexType name='template-with-space' base='xsl:template' derivedBy='extension' >
        <attribute ref='xml:space' />
    </complexType>

    <complexType name='for-each' base='xsl:template-with-space' derivedBy='extension' >
        <element name='sort' type='xsl:sort' minOccurs='0' maxOccurs='unbounded' />
        <attribute name='select' type='xsl:expr' use='required' />
    </complexType>

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:

<complexType name="for-each">
	 <element name="sort" 
           type="xsl:sort" 
           minOccurs='0' 
           maxOccurs='unbounded'/>
	 <mixed>
   	<element ref='xsl:instruction' />
   	<any namespace='##other' />
	</mixed>
</complexType>

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.

<!--  these would all be equivalent (unless someone 
     defined a locally name empty complex type)  -->
<element name="apply-imports" type="empty"/>
<element xmlns:xsd="http://www.w3.org/1999/XMLSchema" name="apply-imports" type="xsd:empty"/>
<element name="apply-imports"/>

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:

<xs:element name='foo'>
  <xs:complexType content='textOnly'/>
</xs:element> 

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.

  <xs:complexType name='haystack' content='mixed'>
   <xs:sequence>
     <xs:element name='thread'/>
     <xs:element name='needle'/>
   </xs:sequence>
  </xs:complexType>

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

  <xs:complexType content='mixed'>
   <xs:element .../>
   . . .
  </xs:complexType>

"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:

<complexType name='bob' content='mixed' >
	<element name='a'/>
	<element name='b'/>
	<element name='c'/>
</complexType>

is equivalent to:

<complexType name='bob' content='mixed' >
 <choice minOccurs='0' maxOccurs='unbounded' >
	<element name='a'/>
	<element name='b'/>
	<element name='c'/>
 </choice>
</complexType>

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:

<complexType name='bob' content='mixed' >
 <sequence minOccurs='m' maxOccurs='n' >
	<element name='a'/>
	<element name='b'/>
	<element name='c'/>
 </sequence>
</complexType>

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

<schema targetNamespace="http://www.w3.org/1999/XMLSchema-instance">
    <simpleType name="urSimpleType"/>
    <simpleType name="string"/>
    <simpleType name="integer"/>
    ....
    <attribute name="type" type="QName"/>
    <attribute name="null" type="boolean"/>
</schema>

XMLSchema.xsd

<schema targetNamespace='http://www.w3.org/1999/XMLSchema">
  <import targetNamespace="http://www.w3.org/1999/XMLSchema-instance"
          schemaLocation="xsi.xsd"/>
  <!-- import of xml namespace goes here   -->

  <!--  since this is not in the instance namespace, 
        it will not be used to resolve
        unqualified names in other schemas   -->
  <simpleType name="XPathApprox"/>
  ...
  <attribute name="type" type="QName"/>
  <attribute name="null" type="boolean"/>
</schema>

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:

 <el xmlns:dt="http://www.w3.org/1999/XMLSchema-datatypes"  
     xsi:type="dt:integer"/>

as opposed to:

<el xsi:type="xsd:integer"/>

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:

<xsd:element name="el" type="xsd:integer"/>

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:

1. It introduces a parallel type hierarchy which would result in unnecessary confusion
2. It doesn't use qualified names for the base datatype, which implies a special rule when the name and base values are the same. Otherwise an unqualified reference should refer an element in the current namespace and failing that then be resolved whatever namespace provides the built-in datatypes.
3. It implies an implicit import of some namespace (to provide the built-in datatypes). If this implied import is the schema namespace, you haven't done anything to reduce the namespace since the entirety of the implicit namespace is still there.

My current thinking on this is that:

• a) schema-datatypes should be the one and only definition of the built-in datatypes
• b) schema-instance should import datatypes (at least implicitly) to resolve the QName type of xsi:type and the boolean type for xsi:null.
• c) schema-instance and schema-datatypes are implicitly imported any any schema processing. If you provide an explicit import for the instance or datatypes, that resource will be used preferentially. Otherwise, the processor will provide them from its resources.
• d) schema for schema can declare any necessary "utility" datatypes, however these are not available outside of schema for schemas without an explicit import and qualified reference.
• e) when a schema interpreter is resolving an unqualified simple type name, it should first look for a matching type in the current namespace and if not found, then look for a matching type in the schema-datatypes namespace.
• f) the base and name attribute should not be allowed to be the same unless the name is urDataType.
• g) schema analysis and authoring environments should report a diagnostic message if a locally-scoped name conflicts with a type name in schema-datatypes. However, parsers should not treat that as an error and resolve to the locally scoped name first.

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

<xsd:simpleType name="ThreeCountries" base="Country" derivedBy="xsd:list">
  <xsd:length value="3" />
  <xsd:separator value=";" />
</xsd:simpleType>

<xsd:element name="threeCountries" type="ThreeCountries" />

<threeCountries>United States of America;Italia;San Marino</threeCountries>

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

<xsd:element name="image">
  <xsd:complexType>
    <anyAttribute namespace="http://www.w3.org/xhtml"
        group="attributesForImg" />
  </xsd:complexType>
</xsd:element>

"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

<xsd:simpleType name="units">
  <enumeration value="cm" />
  <enumeration value="in" />
</xsd:simpleType>

I have no way to define

<height>12.4cm</height>

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

<xsd:complexType name="heightWithUnits">
  <xsd:pattern>
    <xsd:part type="xsd:decimal" />
    <xsd:part value="\p{Zs}*" />
    <xsd:part type="units" />
  </xsd:pattern>
</xsd:complexType> 

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:

<simpleType name="firstType" base="decimal">
  <minInclusive value="1"/>
  <maxInclusive value="10"/>
</simpleType>

<simpleType name="secondType" base="firstType">
  <minInclusive value="2"/>
  <maxInclusive value="5"/>
</simpleType>

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:

<simpleType name="thirdType" base="firstType">
  <minInclusive value="0"/>
  <maxInclusive value="11"/>
</simpleType>

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:

if(a > 1 && a > 2 && a < 5 && a <10) {}

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:

  <s:group name="recur">
    <s:sequence>
      <s:element name="open"/>
      <s:group ref="recur" minOccurs="0" maxOccurs="unbounded"/>
      <s:element name="close"/>
    </s:sequence>
  </s:group>

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

<textEntity name='rights'>All rights reserved.</textEntity>

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:

• ##any
• ##other
• ##local
• list of {uri, ##targetNamespace}

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:

namespace = ##any
              | ##other
              | list of {uri, ##targetNamespace, ##other}

?

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

namespace = ##any 
          | ##other
          | list of {uri, ##targetNamespace, ##local}

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

<xml version='1.0'?>
<!-- XML Schema schema for XML Schemas: Part 1: Structures -->
<!DOCTYPE schema
  PUBLIC "-//W3C//DTD XMLSCHEMA 19991216//EN" 
  "http://www.w3.org/1999/XMLSchema.dtd">

<schema xmlns="http://www.w3.org/1999/XMLSchema" 
        targetNamespace="http://www.w3.org/1999/XMLSchema" 
        blockDefault="#all" 
        elementFormDefault="qualified"  
        version="Id: XMLSchema.xsd,v 1.1 2000/04/06 13:51:05 aqw Exp" 
        xsi:schemaLocation ="http://www.w3.org/1999/XMLSchema.xsd" >

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:

SOAP-ENC:arrayType="xsd:int[3]"

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

SOAP-ENC:arrayType="yourNS:address[3]"

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:

SOAP-ENC:arrayType="xsd:urType[3]"

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.

<!--  circular reference could indicate a urType   -->
<complexType name="urType" base="urType">
    <any minOccurs="0" maxOccurs="unbounded"/>
    <anyAttribute use="optional"/>
<complexType>

<!--  simpleType can inherit from complexType as long as complex type has
not
             required attributes or content.  Could restrict it further to
self references.  -->
<simpleType name="urSimpleType" base="urType"/>

<!--  this could replace content="empty" and serve as the
               basis for most derivations by extension  -->
<complexType name="empty" base="urType" derivedBy="restriction">
    <any maxOccurs="0"/>
    <anyAttribute use="prohibited"/>
</complexType>

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:

ancestor-or-self::*[@implied-attribute][1]/@implied-attribute

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

<xsd:simpleType base="PermissionType" derivedBy="?????"/>

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:

  <complexType name="annotated" base="openAttrs" derivedBy="extension" 
...

<!-- Error here!
   <annotation>
    <documentation>All the things which can occur in any of the
                   attributes controlling derivation or use of derived 
                   definitions</documentation>
    <documentation>A utility type, not for public use</documentation>
   </annotation>
   <enumeration value="list"/>
   <enumeration value="restriction"/>
  </simpleType>
-->

  <complexType name="simpleType" base="annotated" derivedBy="extension" 

...

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.

  <complexType name="simpleType" base="annotated" derivedBy="extension"
abstract="true">
    <element ref="facet" minOccurs="0" maxOccurs="unbounded"/>
    <attribute name="name" type="NCName">
      <annotation>
       <documentation>Can be restricted to required or
forbidden</documentation>
      </annotation>
    </attribute>
    <attribute name="base" type="QName" use="required"/>
     <simpleType base="NMTOKEN">
      <enumeration value="list"/>
      <enumeration value="restriction"/>
     </simpleType>
    </attribute>
  </complexType>

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

<simpleType name="ArrayOfInteger" base="integer" derivedBy="list"/>
   <length value="2"/>
</simpleType>

<simpleType name="MatrixOfInteger" base="ArrayOfInteger" derivedBy="list"/>
   <length value="4"/>
</simpleType>

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:

<simpleType name="MatrixOfInteger" base="ArrayOfInteger"/>
   <dim value="2 4"/>
</simpleType>

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:

<element name="Cat"/>
<element name="Dog"/> 
<element name="????"/> 

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:

• 1.1 The {derivation method} of D is not in the subset, or in the {final} of its {base type definition};
• 1.2 Either
• 1.2.1 They are the same type definition; or
• 1.2.2 B is the {base type definition} or
• 1.2.3 the {base type definition} is not the ur-type definition and is validly derived from B given the subset as defined by this constraint (if the {base type definition} is complex) or validly derived from B given the subset unioned with {list} as defined in Type Derivation OK (Simple) (§5.12) (if the {base type definition} is simple)."

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:

<complexType name="FrameAnnotation">
     <element name="Who" type="string" minOccurs="0"/>
     <element name="What" type="string" minOccurs="0"/>
....
     <attribute ref="xml:lang"/>
</complexType>

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.

<complexType name="empty"/>

<element name="resourceDefRef" abstract="true" type="empty"/>

<element name="resource" equivClass ="resourceDefRef">
    <complexType base="empty" content="mixed">
            <any maxOccurs="unbounded" minOccurs="0"/>
    </complexType>
</element>

<elementType name="resourceRef" equivClasss="resourceDefRef">
    <complexType base="empty">
        <attribute name="href" type="uriReference"/>
    </complexType>
</elementType>

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:

• a) the restriction on equivClass members having a common ancestor type be removed.
• b) that the final attribute of <element> be a boolean. A value of true would inhibit the use of the element as an exemplar.
• c) that the equivClass attribute of <element> become a list of QNames.

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.

<Library 
  xmlns:book  ="http://www.somewhere.org/Book" 
  xmlns:person="http://www.somewhere-else.org/Person" 
  xmlns:xsi   ="http://www.w3.org/1999/XMLSchema/instance" 
  xsi:schemaLocation="http://www.somewhere.org/Examples 
    http://www.somewhere.org/Examples/Book.xsd 
    http://www.somewhere-else.org/Person 
    http://www.somewhere-else.org/Person/Person.xsd">
 <BookCatalogue>
  <book:Book>
  <book:Title>Illusions The Adventures of a Reluctant 
    Messiah</book:Title> 
  <book:Author>Richard Bach</book:Author> 
  <book:Date>1977</book:Date> 
  <book:ISBN>0-440-34319-4</book:ISBN> 
  <book:Publisher>Dell Publishing Co.</book:Publisher> 
  </book:Book>

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:

1. The schema documents http://www.somewhere.org/Examples/Book.xsd and http://www.somewhere-else.org/Person/Person.xsd might <import> schemas with appropriate target namespaces (that is, http://www.somewhere.org/Book and none, for <Book> and <Library> respectively);
2. The user who invokes schema validation may supply such schemas, either in the form of schema documents, or in some application-specific built-in form.

"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:

<xs:element name="car">
   <xs:complexType model="empty">
    . . .
    <xs:attribute name="regRef" type="dt:integer"/>
    <xs:attribute name="regState" type="twoLetterCode"/>
   </xs:complexType>
  </xs:element>
 </xs:complexType>

 <xs:key name="carRef" >
  <xs:selector>.//car[@regRef]</xs:selector>
   <xs:field>@regRef</xs:field>
   <xs:field>@regState</xs:field>
 </xs:keyref>
</xs:element>

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

• XPath expression in XSL: match="/cars/car[@name='volvo']"
• Path in SVG: <path d="M 100 100 L 140 100 L 120 140 z"/>

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:

• compression, produces smaller XML streams (SVG paths,...)
• usage of attribute strings for readability (XPath expressions.,,,)
• usage of attribute strings for compactness (XPath expressions,...)
• ...

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.

• Add new XML Schema data type which represents "MicroParsed" attribute values. Make it a subtype of "string" with all its facets. Schema writers can now derive their own MicroParsed data types, one for each stereotype they want to encode as attribute.
• In this new data type add a reference to a complexType. This referenced schema defines how to encode the contents (information model) of the attribute string ("attribute form") as an XML element tree ("element form"). Note: Maybe this reference should be a new facet for the string data type. Note: With this design it is possible to encode the same stereotype as either XML attribute string or XML element tree in documents.
• In this new data type add a reference to the attribute's "form specification", i.e. where to find more information on how to construct attribute strings from the underlying information model.
• All available information in the stereotypes information model must be encoded in the "element form" and the information encoded in the "attribute form" must be a "subset" of the information encoded in the element form's encoding (similar to applying a grove plan before encoding as attribute). The "element form" is considered a "complete" encoding form (contains all information in the information model).
• Information set: Add an extra optional property to attribute information item. property: "parsed" sequence<element-info-item[zero or one]>
• Recommend that all Schema authors first create an information model for the stereotype then create encoding "form"s for the primary XML element encoding form and last the corresponding XML attribute strings form.
• DOM framework: Create a new software artifact called "DOMAttributeMicroParser"

interface DOMAttributeMicroParser {
    readonly  attribute string  name;
    readonly  attribute string  namespace;

    /* parse attribute string and create the corresponding element tree */
    long      parse(in DOMAttribute from, out DOMElement to);

    /* Traverse the element tree and create corresponding attribute
       string expression */
    long      construct(in DOMElement from, out DOMAttribute to);
};

• DOM framework [Optional]: Create a subclass to DOM Attribute called "DOMParsedAttribute"

interface DOMParsedAttribute : DOMAttribute {
     attribute DOMElement  fParsed;  /* parsed attribute */
};

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,

  <xsd:simpleType name="MyTimeDuration"
                  base="xsd:timeDuration">
      <xsd:pattern
       value="-?P(\d+D)?(T(\d+H)?(\d+M)?(\d+(\.\d+)?S)?)?" />
  </xsd:simpleType>

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]

• http://www.w3.org/TR/2000/WD-xmlschema-0-20000407/
• http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/
• http://www.w3.org/TR/2000/WD-xmlschema-2-20000407/

"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:

• http://www.w3.org/1999/XMLSchema/Instance
• http://www.w3.org/1999/XMLSchema#Instance

"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:

     <xml version='1.0'?>
     <!-- XML Schema schema for XML Schemas: Part 1: Structures -->
     <!DOCTYPE schema
       PUBLIC "-//W3C//DTD XMLSCHEMA 19991216//EN" 
       "http://www.w3.org/1999/XMLSchema.dtd">

     <schema xmlns="http://www.w3.org/1999/XMLSchema" 
       targetNamespace="http://www.w3.org/1999/XMLSchema" 
       blockDefault="#all" elementFormDefault="qualified" 
       version="Id: XMLSchema.xsd,v 1.1 2000/04/06 13:51:05 aqw Exp"
       xsi:schemaLocation ="http://www.w3.org/1999/XMLSchema.xsd" >

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:

<xsd:complexType name="ChoiceOfSequences1">
  <xsd:choice>
     <xsd:sequence>
         <xsd:element name="a" type="typeOfA"/>
         <xsd:element name="b" type="typeOfB"/>
         <xsd:element name="d" type="typeOfD"/>
      </xsd:sequence>
      <xsd:sequence>
          <xsd:element name="a" type="typeOfA"/>
          <xsd:element name="c" type="typeOfC"/>
      </xsd:sequence>
    </xsd:choice>
  </xsd:complexType>

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:

<xsd:complexType name="ChoiceOfSequences2">
  <xsd:choice>
     <xsd:sequence>
         <xsd:element name="a" type="typeOfA1"/>
         <xsd:element name="b" type="typeOfB"/>
      </xsd:sequence>
      <xsd:sequence>
          <xsd:element name="a" type="typeOfA2"/>
          <xsd:element name="c" type="typeOfC"/>
      </xsd:sequence>
    </xsd:choice>
  </xsd:complexType>

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:

<xsd:complexType name="ChoiceOfChoices3">
  <xsd:choice>
     <xsd:choice>
         <xsd:element name="a" type="typeOfA1"/>
         <xsd:element name="b" type="typeOfB"/>
      </xsd:choice>
      <xsd:choice>
          <xsd:element name="a" type="typeOfA2"/>
          <xsd:element name="c" type="typeOfC"/>
      </xsd:choice>
    </xsd:choide>
  </xsd:complexType>

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:

<!-- definition in 1.0 schema   -->
<complexType name="pipe">
    <element ref="material" minOccurs="0" maxOccurs="1"/>
</complexType>

<!--  definition in 1.0+ schema   -->
<complexType name="pipe">
    <element ref="material" minOccurs="0" maxOccurs="1"/>
    <any minOccurs="0" maxOccurs="unbounded"/>
    <anyAttribute/>
</complexType>

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:

<complexType name="pipe">
    <any minOccurs="0" maxOccurs="unbounded"/>
    <anyAttribute/>
</complexType>

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:

<complexType name="base">
    <anyAttribute/>
</complexType>

<complexType name="derived" base="base" derivedBy="restriction">
    <attribute name="value" use="required"/>
</complexType>

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

<simpleType name="derived" base="xsdt:string">
    <!--  this facet isn't declared for string   -->
    <pattern value="\d*"/>
<simpleType>

"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:

1. schema element have a targetPublicIdentifier attribute in addition to a targetNamespace.
2. xsi:schemaPublic be a list of public identiers
3. xsi:schemaSystem be a list of URI's
4. xsi:defaultNamespace would identify the namespace to be used for unqualified elements. (see note)
5. A publicIdentifier simple type be added to the built-in datatypes.
6. The use of a processing instruction as an alternative mechanism for specifying schema resources for XML 1.0 compatible documents. Since these would not involve multiple namespaces or resources, I'd recommend something like the following to appear before the document element:

<?xsi:schema defaultNamespace PUBLIC pubid sysid ?>
<?xsi:schema defaultNamespace SYSTEM sysid ?>

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