RE: Question about

Thanks, both of you for your quick responses.
 
Obviously, my thinking was that the following comparison
 
    Key={empty,"Something"}  <-> keyref={empty,"Something"}
 
would actually be evaluated. You've nicely explained why this turns out not
to be the case.
 
So, let me ask a design workaround follow-up: if I do want to use a
multifield key, but also want to permit the instance author to omit
specification of a value of one of the fields in either a key or keyref
element, then can I "simulate" the above behavior by specifying some
arbitrary default for the fields, e.g., changing by type declarations to:
 
     <xs:complexType name="KeyElementType">
          <xs:complexContent>
               <xs:extension base="xs:anyType">
                    <xs:attribute name="KeyField1" type="xs:string"
default="%Not specified%"/>
                    <xs:attribute name="KeyField2" type="xs:string"
default="%Not specified%"/>
               </xs:extension>
          </xs:complexContent>
     </xs:complexType>
     <xs:complexType name="KeyrefElementType">
          <xs:complexContent>
               <xs:extension base="xs:anyType">
                    <xs:attribute name="KeyrefField1" type="xs:string"
default="%Not specified%"/>
                    <xs:attribute name="KeyrefField2" type="xs:string"
default="%Not specified%"/>
               </xs:extension>
          </xs:complexContent>
     </xs:complexType>

And second, is it possible to make the default attribute equal to a
length-zero string (e.g. default=""), or would this just be seen as an emtpy
node?
 
By the way (to make clear this isn't just bloody-mindedness!) the actual
situation in question is that in a pre-existing schema that's under
revision, there exists an identifier with two parts (a root and an optional
extension) that was an "informal" target for references. In the revised
version I'd like to keep this identifier, but formalize its use as a
reference target by means of uniqueness constraints, while not however
losing (some semblance of) the optionality of the extension.
 
John

This email was sent on 1/17/04 at 11:12 AM.