Re: <key> problems.

Kevin Burges <xmldude@burieddreams.com> writes:

> I'm trying to impliment a <key> as below but for some reason it
> doesn't work. Is it me that's wrong, or XMLSpy 4.1?
> 
> I have a document like this:
> 
> <IDs>
>     <Form FormID="1">
>         <Field FieldID="1"/>
>     </Form>
>     <Form FormID="2">
>         <Field FieldID="1"/>
>     </Form>
> </IDs>
> 
> In the Schema I have the following KEY on the <IDs> element:
> 
> <xs:key name="FieldsByFormKey">
>     <xs:selector xpath="Form/Field"/>
>     <xs:field xpath="../@FormID"/>
>     <xs:field xpath="@FieldID"/>
> </xs:key>
> 
> I believe this document should be valid against that Key constraint,
> but XMLSpy4.1 says that the second <Field> element produces a
> duplicate Key value, and hence is invalid.
> 
> By my understanding there should be two unique keys generated:
>  {1 1) (2 1}
> 
> So, it is me or XMLSpy at fault?

Both!

Your first <field> is not allowed -- you can't use '..' in the xpaths
for fields or selectors.  If what you're trying to say is that fields
are unique within forms, and forms are unique within IDs, you need two 
keys.  XML Schema won't support two-stage keys until a subsequent
version.

XML Spy should have bounced your xpath.

ht
-- 
  Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
          W3C Fellow 1999--2001, part-time member of W3C Team
     2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
	    Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
		     URL: http://www.ltg.ed.ac.uk/~ht/

Received on Monday, 19 November 2001 06:46:45 UTC