XML Editor
Sign up for a WebBoard account Sign Up Keyword Search Search More Options... Options
Chat Rooms Chat Help Help News News Log in to WebBoard Log in Not Logged in
Show tree view Topic
Topic Page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Go to previous topicPrev TopicGo to next topicNext Topic
Postnext
pa donSubject: No Error when Duplicate key is found
Author: pa don
Date: 29 Mar 2005 01:29 AM
Hello,
I am trying to define unique constraint such that given song can have at most one entry for each singer in each genere.
My XML file looks like
---------------------------------------------------------------
<?xml version="1.0"?><!DOCTYPE Songs []>
<Songs xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="file:///c:/test.xsd">
<Sgr name="Eagles" genre="rock">
<Song lg="en" ti="Hotel California"/>
<Song lg="en" ti="Seven Bridges Road"/>
</Sgr>
<Sgr name="H Belafonte" genre="reggae">
<Song lg="cpe" ti="Day O"/>
<Song lg="en" ti="Jamaica Farewell"/>
</Sgr>
<Sgr name="Eagles" genre="rock">
<Song lg="en" ti="Hotel California"/>
</Sgr>
</Songs>
---------------------------------------------------------------
And the corresponding xsd looks like

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">

<xs:element name="Songs">
<xs:complexType>
<xs:sequence>
<!-- <xs:element maxOccurs="unbounded" ref="Sgr"/> -->
<xs:element name="Sgr" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<!-- <xs:element maxOccurs="unbounded" ref="Song"/> -->
<xs:element name="Song" maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="lg" use="required" type="xs:NCName"/>
<xs:attribute name="ti" use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="genre" use="required" type="xs:NCName"/>
<xs:attribute name="name" use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>

</xs:complexType>
<xs:unique name="Sgr_Song_Genere_Pair">
<xs:selector xpath="Sgr"/>
<xs:field xpath="@name"/>
<xs:field xpath="@genre"/>
<xs:field xpath="Song/@ti"/>
</xs:unique>
</xs:element>
</xs:schema>
---------------------------------------------------------------
However I do not get any errors for duplicate values.

What is that I am missing ?
Thx,
Ash

Postnext
Alberto MassariSubject: No Error when Duplicate key is found
Author: Alberto Massari
Date: 31 Mar 2005 04:14 AM
Hi Ash,
this looks like a limitation of the Xerces-C++ validator; you should rely
on the other validators (.NET, Xerces-J, XSV) in order to check for the
validity of your document.

However, your identity constraint is not correct: the spec mandates that
each "field" component must resolve to 0 or 1 elements, while the Song/@ti
XPath can return 2 elements in some cases. BTW, some validators flag this
error, some don't and silently enforce the constraint only on the first
element.
Unfortunately, it seems to me that the structure of your XML doesn't allow
you to write a correct xs:unique statement; you need to enforce the uniqueness
constraint on the Song elements, but using attributes coming from the
parent element Sgr, but the XPath syntax for the xs:field statement does
not allow the usage of the parent axis ".."
An alternative is to split the uniqueness constraint on two levels: at
the level of the Songs element you enforce that the Sgr child elements
will be unique with regard to the @name and @genre; then, at the Sgr
level you enforce that each Song/title must be unique.

Hope this helps,
Alberto

Postnext
pa donSubject: No Error when Duplicate key is found
Author: pa don
Date: 31 Mar 2005 09:29 AM
Thank you

Posttop
Alberto MassariSubject: No Error when Duplicate key is found
Author: Alberto Massari
Date: 01 Apr 2005 08:41 AM
Hi Ash,
just a quick follow-up on the issue: the internal validator (Xerces-C++)
can indeed find the duplicate element (although it will look just at the
first hit in the case of a xs:field matching more than one item, like
other validators).
To see the errors you need to give a type (e.g. xs:string) to all the
attributes involved in the construction of the key, Sgr/@name and
Sgr/Song/@ti. This because they are otherwise defined as being of type
xs:anySimpleType, and the XML Schema specs say (§2.2.1.2 Simple Type
Definition) "the mapping from lexical space to value space is unspecified
for items whose type definition is the ·simple ur-type definition·.
Accordingly this specification does not constrain processors' behaviour
in areas where this mapping is implicated, for example [...] checking
identity constraints involving such items. Note: The Working Group
expects to return to this area in a future version of this specification."

In simpler words, while you can say for sure that "9.0" is equal to "9"
if both of them are lexical values for a xs:decimal datatype because
they are two representation of the same value, you cannot say that
"Hotel California" is the same thing of "Hotel California" if they are
instances of the xs:anySimpleType datatype. The specs leaves the
implementors free of behave as they want: it looks like the majority
has choosen to perform a byte-by-byte comparison of the two representations,
while Xerces-C always says they are different.

I have reported the issue to the Xerces-C team, and I hope they will
vote for fixing this behavior; in the meanwhile, I would suggest (in order
to avoid yet another grey area of the specs) to give an xs:string type
to your attributes.

Thanks,
Alberto

 
Topic Page 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Go to previous topicPrev TopicGo to next topicNext Topic
Download A Free Trial of Stylus Studio 6 XML Professional Edition Today! Powered by Stylus Studio, the world's leading XML IDE for XML, XSLT, XQuery, XML Schema, DTD, XPath, WSDL, XHTML, SQL/XML, and XML Mapping!  
go

Log In Options

Site Map | Privacy Policy | Terms of Use | Trademarks
Stylus Scoop XML Newsletter:
W3C Member
Stylus Studio® and DataDirect XQuery ™are from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2016 All Rights Reserved.