Re: Problem with UNIQUE constraint

(note the change of list)

Is this a possible consideration for 1.1 or 2.0?  I.e. should key/keyref
allow reference to complex elements that have simple content?  No big deal
to me, but we have at least one user that misses it.  Thanks.

Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142

----- Forwarded by Noah Mendelsohn/Cambridge/IBM on 03/27/2002 11:02 AM
                      Jeni Tennison                                                                                                     
                      <jeni@jenitenniso        To:       Gary Cramblitt <>                                     
            >                   cc:, (bcc: Noah Mendelsohn/Cambridge/IBM)                     
                      Sent by:                 Subject:  Re: Problem with UNIQUE constraint                                             
                      03/27/2002 07:48                                                                                                  
                      Please respond to                                                                                                 
                      Jeni Tennison                                                                                                     

Hi Gary,

> Obviously, the error occurs because the field xpath resolves to a
> complexType called "HasClassification". But HasClassification is an
> element with simpleContent and an optional attribute.

I hadn't noticed that limitation before, but the Rec definitely says
that the field that you select has to be an element or attribute with
a simple type, rather than saying an attribute or an element with
simple content. I guess this will be addressed when keys are reviewed
for the next version anyway, but it does seem a bit of a drawback.

> Can anyone suggest a workaround? Is there some way to define the
> xpath to resolve only to the RadioService element so that the schema
> will validate?

I can't see a way round it that doesn't involve changing your markup
language -- you could drop the Class attribute from the RadioService
element, or you could have the RadioService element hold its value
inside a dedicated attribute or child element.

But I can't see an workaround within the XML Schema. You should
probably remove the identity constraint there, and add a test using
embedded Schematron instead:

  <sch:rule context="Rec_SelRadioSrvc">
    <sch:report test="preceding-sibling::Rec_SelRadioSrvc
                        [LineID = current()/LineID and
                         RadioService = current()/RadioService]">
      This <sch:name /> has the same <sch:name path="LineID" />
      and <sch:name path="RadioService" /> as a previous <sch:name />.

By the way, I think that you're probably using the identity constraint
incorrectly. If you want to test that each Rec_SelRadioSrvc element
has a unique combination of LineID and RadioService, then you need to
place the identity constraint on the declaration of the element that's
the *parent* of the Rec_SelRadioServc element, as follows:

  <xs:unique name="ID_SelRadioSrvc">
    <xs:selector xpath="Rec_SelRadioSrvc"/>
    <xs:field xpath="LineID"/>
    <xs:field xpath="RadioService"/>

As you currently have it, all you're testing is that the LineID and
RadioService of one Rec_SelRadioSrvc at a time. There isn't much point
doing that unless you're using the identity constraint sneakily to
test a co-occurrence constraint, which I don't think is the case here.



Jeni Tennison

Received on Wednesday, 27 March 2002 11:07:38 UTC