Re: Use of key/keyref - any best practices? warnings?

> My organization is going to start looking at the use of key/keyref. I 
> haven't seen many questions or recommendations about the use of this 
> feature. Is anyone really using this functionality? What sort of 
> problems (if any) are you finding? Is this functionality well supported 
> by the tools and vendors - or is this another one of these features they 
> are not implementing?

Hi Danny,

I have personally been against using this feature as it strongly ties 
you to one schema implementation-- namely XML Schema. While XML Schema 
is not a bad thing, that type of lock-in has always scared me. If you 
are going to use it there are several things you need to be aware of:

(1) Scope. Like Michael Kay said scope is very important. If you are not 
defining the keys and keyrefs in the same complexType then you need to 
make sure that the keyref is on an ancestor of the key. Otherwise you 
run into interop problems with different implementations.

(2) Namespaces. In order to correctly refer to a key in an XML Schema 
with a targetNamespace and have it work the same across multiple 
implementations, you *must* have the reference to the keyname be both 
prefixed and qualified. Having your targetNamespace and default 
namespace declaration be the same is not enough. I seem to recall 
needing to have the XPath steps to the key prefixed and qualified as well.

(3) Sometimes you have a container that contains multiple keyrefs 
grouped together. If you plan on doing this then the container element 
should be at the "First common ancestor" (or lowest common denominator) 
of the various keys.

(4) xs:unique. Within the spec it is defined that where you have an 
xs:unique and an xs:key you can simply utilize the xs:unique /as/ an 
xs:key. The support for this feature is spotty-- don't use it. Anytime 
you need to have a key, use xs:key. Anytime you need to have uniqueness 
constraint use xs:unique. Anytime you need both, use both.

Some of the benefits of key/keyref include the ability to have multiple 
keys per element, the ability to use different types for your keys (not 
be contrained to NMTOKEN as in ID/IDREF), add extensive documentation in 
the link within the schema about its role/purpose.

I know that the Commercial Mortgage Industry Standards Maintenance 
Orginization (CMISMO) just released an industry specific best practices 
guide that contained two sections of key/keyref. There is some good info 
in there [1]


[1] 
http://www.mismo.org/mismo/commercial/MISMO%20CWG%20Best%20Practices%20Guide%20v1_0.pdf

All the best,
Jeff Rafter

Received on Sunday, 27 February 2005 14:47:03 UTC