W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > January to March 2002

Re: Problem with UNIQUE constraint

From: <noah_mendelsohn@us.ibm.com>
Date: Wed, 27 Mar 2002 10:52:22 -0500
To: www-xml-schema-comments@w3.org
Cc: Gary Cramblitt <garycramblitt@comcast.net>, jeni@jenitennison.com
Message-ID: <OF6D2070E3.FA8CF9BE-ON85256B89.00571264@lotus.com>
(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 <garycramblitt@comcast.net>                                     
                      n.com>                   cc:       xmlschema-dev@w3.org, (bcc: Noah Mendelsohn/Cambridge/IBM)                     
                      Sent by:                 Subject:  Re: Problem with UNIQUE constraint                                             
                      xmlschema-dev-req                                                                                                 
                      uest@w3.org                                                                                                       
                                                                                                                                        
                                                                                                                                        
                      03/27/2002 07:48                                                                                                  
                      AM                                                                                                                
                      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 />.
    </sch:report>
  </sch:rule>

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"/>
  </xs:unique>

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.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/
Received on Wednesday, 27 March 2002 11:07:38 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:15:33 UTC