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