human-targeted annotation for an Identity-constraint Definition (valid schema) Annotations provide for human- and machine-targeted annotations of schema components. In the test the human-targeted annotation is provided for an Identity-constraint Definition. human-targeted misplaced annotation for an Identity-constraint Definition (invalid schema) Annotations provide for human- and machine-targeted annotations of schema components. In the test the human-targeted annotation is provided for an Identity-constraint Definition. The annotation is misplaced. human-targeted double annotation for an Identity-constraint Definition (invalid schema) Annotations provide for human- and machine-targeted annotations of schema components. In the test the human-targeted annotation is provided for an Identity-constraint Definition. The annotation is specified twice. machine-targeted annotation for an Identity-constraint Definition (valid schema) Annotations provide for human- and machine-targeted annotations of schema components. In the test the machine-targeted annotation is provided for an Identity-constraint Definition. machine-targeted misplaced annotation for an Identity-constraint Definition (invalid schema) Annotations provide for human- and machine-targeted annotations of schema components. In the test the machine-targeted annotation is provided for an Identity-constraint Definition. The annotation is misplaced. machine-targeted double annotation for an Identity-constraint Definition (invalid schema) Annotations provide for human- and machine-targeted annotations of schema components. In the test the machine-targeted annotation is provided for an Identity-constraint Definition. The annotation is specified twice. fields may have different types (valid schema) Define a uniqueness constraint with fields of different types. values of the fields are checked for equality: type is decimal, values are 3.0 and -3 (valid schema) The equality and inequality conditions appealed to in checking these constraints apply to the value of the fields selected, so that for example 3.0 and 3 would be conflicting keys if they were both number, but non-conflicting if they were both strings, or one was a string and one a number. In the test the fields of type decimal have values 3.0 and -3. values of the fields are checked for equality: type is decimal, values are 3.0 and 3 (valid schema) The equality and inequality conditions appealed to in checking these constraints apply to the value of the fields selected, so that for example 3.0 and 3 would be conflicting keys if they were both number, but non-conflicting if they were both strings, or one was a string and one a number. In the test the fields of type decimal have values 3.0 and 3. values of the fields are checked for equality: type is decimal, values are 3.0 and 3.0 (valid schema) The equality and inequality conditions appealed to in checking these constraints apply to the value of the fields selected, so that for example 3.0 and 3 would be conflicting keys if they were both number, but non-conflicting if they were both strings, or one was a string and one a number. In the test the fields of type decimal have values 3.0 and 3.0. values of the fields are checked for equality: type is string, values are 3.0 and 3 (valid schema) The equality and inequality conditions appealed to in checking these constraints apply to the value of the fields selected, so that for example 3.0 and 3 would be conflicting keys if they were both number, but non-conflicting if they were both strings, or one was a string and one a number. In the test the fields of type string have values 3.0 and 3. values of the fields are checked for equality: type is string, values are 3.0 and 3.0 (valid schema) The equality and inequality conditions appealed to in checking these constraints apply to the value of the fields selected, so that for example 3.0 and 3 would be conflicting keys if they were both number, but non-conflicting if they were both strings, or one was a string and one a number. In the test the fields of type string have values 3.0 and 3.0. values of the fields are checked for equality: string(3.0) compares with decimal(-3) (valid schema) The equality and inequality conditions appealed to in checking these constraints apply to the value of the fields selected, so that for example 3.0 and 3 would be conflicting keys if they were both number, but non-conflicting if they were both strings, or one was a string and one a number. In the test the first field of type string has value "3.0". The second field of type decimal has value "-3". values of the fields are checked for equality: string(3.0) compares with decimal(3) (valid schema) The equality and inequality conditions appealed to in checking these constraints apply to the value of the fields selected, so that for example 3.0 and 3 would be conflicting keys if they were both number, but non-conflicting if they were both strings, or one was a string and one a number. In the test the first field of type string has value "3.0". The second field of type decimal has value "3". values of the fields are checked for equality: string(3.0) compares with decimal(3.0) (valid schema) The equality and inequality conditions appealed to in checking these constraints apply to the value of the fields selected, so that for example 3.0 and 3 would be conflicting keys if they were both number, but non-conflicting if they were both strings, or one was a string and one a number. In the test the first field of type string has value "3.0". The second field of type decimal has value "3.0". values of the fields are checked for equality: string(3.0) compares with string(3) (valid schema) The equality and inequality conditions appealed to in checking these constraints apply to the value of the fields selected, so that for example 3.0 and 3 would be conflicting keys if they were both number, but non-conflicting if they were both strings, or one was a string and one a number. In the test the first field of type string has value "3.0". The second field of type string has value "3". values of the fields are checked for equality: string(3.0) compares with string(3.0) (valid schema) The equality and inequality conditions appealed to in checking these constraints apply to the value of the fields selected, so that for example 3.0 and 3 would be conflicting keys if they were both number, but non-conflicting if they were both strings, or one was a string and one a number. In the test the first field of type string has value "3.0". The second field of type string has value "3.0". values of the fields are checked for equality: decimal(3.0) compares with decimal(-3) (valid schema) The equality and inequality conditions appealed to in checking these constraints apply to the value of the fields selected, so that for example 3.0 and 3 would be conflicting keys if they were both number, but non-conflicting if they were both strings, or one was a string and one a number. In the test the fields have local type decimal and values "3.0" and "-3". values of the fields are checked for equality: decimal(3.0) compares with decimal(3) (valid schema) The equality and inequality conditions appealed to in checking these constraints apply to the value of the fields selected, so that for example 3.0 and 3 would be conflicting keys if they were both number, but non-conflicting if they were both strings, or one was a string and one a number. In the test the fields have local type decimal and values "3.0" and "3". values of the fields are checked for equality: decimal(3.0) compares with decimal(3.0) (valid schema) The equality and inequality conditions appealed to in checking these constraints apply to the value of the fields selected, so that for example 3.0 and 3 would be conflicting keys if they were both number, but non-conflicting if they were both strings, or one was a string and one a number. In the test the fields have local type decimal and values "3.0" and "3.0". values of the fields are checked for equality: string(3.0) compares with string(3) (valid schema) The equality and inequality conditions appealed to in checking these constraints apply to the value of the fields selected, so that for example 3.0 and 3 would be conflicting keys if they were both number, but non-conflicting if they were both strings, or one was a string and one a number. In the test the fields have local type string and values "3.0" and "3". values of the fields are checked for equality: string(3.0) compares with string(3.0) (valid schema) The equality and inequality conditions appealed to in checking these constraints apply to the value of the fields selected, so that for example 3.0 and 3 would be conflicting keys if they were both number, but non-conflicting if they were both strings, or one was a string and one a number. In the test the fields have local type string and values "3.0" and "3.0". In one namespace Identity-constraint definition names must be unique: the names are KEY0 and KEY1 (valid schema) Declare an element. Define a key identity constraint. Define another key identity constraint with another name. Check that the schema is valid. In one namespace Identity-constraint definition names must be unique: the names are KEY1 and KEY1 (invalid schema) Declare an element. Define a key identity constraint. Define another key identity constraint with the same name. Check that the schema is invalid. constraints have separate symbol space (valid schema) With the same name declare a global element, a local element, an attribute, define a type and a constraint. Check that there is no name clash. Identity-constraint definition identities must be unique: different namespaces (valid schema) Declare an element. Define a key identity constraint and a keyref to that key inside the element declaration. Declare another element with the same key and keyref. Check that if the second element declaration is in the same namespace, that the schema is invalid, otherwise it is valid. Identity-constraint definition identities must be unique: the same namespace (invalid schema) Declare an element. Define a key identity constraint and a keyref to that key inside the element declaration. Declare another element with the same key and keyref. Check that if the second element declaration is in the same namespace, that the schema is invalid, otherwise it is valid.