|
|
 next
|
  Subject: No Error when Duplicate key is found
Author: (Deleted User)
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
|
 top
|
Subject: No Error when Duplicate key is found
Author: (Deleted User)
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
|
|
|
|
