- 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
(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