This issue was originally reported by Neil Graham.

This was R-172
(http://www.w3.org/2001/05/xmlschema-rec-comments.html#pfiurTypeIdConstr).

Consider the schema:

      <xsd:schema
        xmlns="http://schematests.com"
        xmlns:xsd="http://www.w3.org/2001/XMLSchema"
        targetNamespace="http://tests.com">

        <xsd:element name="root">
            <xsd:complexType>
                <xsd:sequence>
                    <xsd:element name="name" maxOccurs="unbounded"/>
                </xsd:sequence>
            </xsd:complexType>
            <xsd:key name="nameKey">
                <xsd:selector xpath="./name"/>
                <xsd:field xpath="."/>
            </xsd:key>

        </xsd:element>

      </xsd:schema>

Since no type is declared for the local "name" element, by the
properties tableaus in [1], it must have the ur-type.

Consider the instance document

      <my:root
        xmlns:my="http://tests.com"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://tests.com idAnytype.xsd">
        <name>Jack Daniels<name>

        <name>Johnny Walker<name>

        <name>Sam Adams<name>
      <my:root>

From the 3rd point of [2]:

   3 For each node in the target node set all of the {fields}, with
     that node as the context node, evaluate to either an empty node-set 
     or a node-set with exactly one member, which must have a simple type. 

[3] tells us that the ur-type can behave as a simpleType "according to
context":

   [Definition:]  A distinguished ur-type definition is present in 
   each XML Schema, serving as the root of the type definition hierarchy 
   for that schema. The ur-type definition, whose name is anyType, has the 
   unique characteristic that it can function as a complex or a simple 
   type definition, according to context."

This raises two questions:
 
* Is it valid for a <field> to match an element with the ur-type
definition under any circumstances?

* If such a match may sometimes be valid (presumably when the element
only contains textual content):

   - If the element contains text, in which value space should the
     schema-normalized value of the field be considered to lie?  This
     will be significant in the case of keyref matches, especially in
     light of the recent discussions concerning the incomparability of
     values from disjoint value spaces.

   - I presume that an error should be raised if the instance of the
     ur-typed element actually contains element content?  Or should
     the <field> match simply fail?

[1]: http://www.w3.org/TR/xmlschema-1/#declare-element


[2]:
http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#section-Identity-constraint-Definition-Validation-Rules
(in version of May 2001; or
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#d0e13819 in Second
Edition

[3]: http://www.w3.org/TR/xmlschema-1/#key-urType 

See:
http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JulSep/0085.html

Henry's response:
http://lists.w3.org/Archives/Public/www-xml-schema-comments/2002JulSep/0089.html

Discussed at the 2003-10-17 telecon.

    RESOLVED: (a) to class R-172 as clarification with erratum, and
    instruct the editor to draft an erratum which restricts fields to
    matching types which have LV mappings (informally, 'concrete'
    simple types), and (b) make a note to come back to this in 1.1,
    after solving RQ-024 and RQ-141 (the issue about abstract simple
    types).

The underlying issue applies to both Structures and Datatypes.  This
Bugzilla entry is for Structures.