Thanks, this is the type of input I was looking for. Locking into XML 
schema is not necessarily a problem for us (currently anyway). I'll take a 
look at the document you site.

..dan

At 06:46 AM 2/27/2005, you wrote:
>>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

---------------------------------------------------------------------------
Danny Vint

Specializing in Panoramic Images of California and the West
http://www.dvint.com

voice: 510-522-4703


     



From nwh@a... Sun Feb 27 21:10:10 2005
Received: from lisa.w3.org ([128.30.52.41])
	by frink.w3.o