- From: Sandy Gao <sandygao@ca.ibm.com>
- Date: Fri, 18 Nov 2005 09:28:11 -0500
- To: "Tishkin, Eugene" <etishkin@mackenziefinancial.com>
- Cc: xmlschema-dev@w3.org
- Message-ID: <OF97A91AB7.78C5D48D-ON852570BD.004EE025-852570BD.004F7E67@ca.ibm.com>
I think the current 4.1 looks fine. If there is anything to be clarified,
it should be clause 3:
"3 For each node in the ·target node set· all of the {fields}, with that
node as the context node, evaluate to either an empty node-set or a
node-set with exactly one member, which has a simple type. ..."
This may lead people (especially whose native language is not English,
like me) to believe that either "all the fields" need to resolve, or none
of them. Whereas the intention is for "each one of those fields", it
resolves to 0 or 1 nodes.
Thanks,
Sandy Gao
XML Parser Development, IBM Canada
(1-905) 413-3255
sandygao@ca.ibm.com
"Tishkin, Eugene" <etishkin@mackenziefinancial.com>
11/18/2005 08:59 AM
To
Sandy Gao/Toronto/IBM@IBMCA
cc
<xmlschema-dev@w3.org>
Subject
RE: unique constraint interpretation.
In order to avoid misinterpretations I would like to suggest a change to
the unique constraint definition as follows.
Add an additional clause into the 3.11.4 paragraph:
3.11.4 Identity-constraint Definition Validation Rules
...
4.1.1 The ·target node set· is a subset of the ·qualified node set·, that
is, every member of the ·target node set· is also a member of the
·qualified node set· however not every member of ·taget node set· is a
member of ·qualified node set·.
...
Thanks
Eugene.
-----Original Message-----
From: Sandy Gao [mailto:sandygao@ca.ibm.com]
Sent: Tuesday, November 15, 2005 11:03 PM
To: Tishkin, Eugene
Cc: xmlschema-dev@w3.org
Subject: Re: unique constraint interpretation.
Just re-read the relevant clause in the spec a few times and came to the
conclusion that Xerces indeed has a bug. That is, the quoted conclusion is
not correct, and the testcase attached to 18405 should be valid.
Thanks,
Sandy Gao
XML Parser Development, IBM Canada
(1-905) 413-3255
sandygao@ca.ibm.com
"Tishkin, Eugene" <etishkin@mackenziefinancial.com>
Sent by: xmlschema-dev-request@w3.org
11/09/2005 09:31 AM
To
<xmlschema-dev@w3.org>
cc
Subject
unique constraint interpretation.
Hi,
The below is the comment from Xerces parser BUG 18405 report:
================================================
"3 For each node in the
·target node set·
all of the
{fields},
with that node as the context node, evaluate to either an empty node-set
or a
node-set with exactly one member, which must have a simple type."
The target node set is the set of nodes on which the selector is matched.
Note
that this condition must hold for *any* identity constraint; only in
bullet 4
of the tableau are the differences between key and unique described.
Therefore, it seems clear that, if a selector matches, then either all of
the
fields must match or none of them must match; even for xsd:unique, you
can't
have some fields matching.
=========================================================
Especially I'm interested in the conclusion:
"Therefore, it seems clear that, if a selector matches, then either all of
the
fields must match or none of them must match; even for xsd:unique, you
can't
have some fields matching."
Is this a correct interpretation of unique constraint?
Regards,
Eugene
This e-mail and any attachments may contain confidential information. Any
distributing, copying or reliance upon the contents of this e-mail by
anyone other
than the intended recipient is strictly prohibited. If you have received
this e-mail
accidentally, please delete it and notify the sender. Although this
message has been
screened for viruses, we cannot guarantee that our virus scanner will
detect all
viruses and take no responsibility for any damage or loss that may be
caused by its
contents.
This e-mail and any attachments may contain confidential information. Any
distributing, copying or reliance upon the contents of this e-mail by
anyone other
than the intended recipient is strictly prohibited. If you have received
this e-mail
accidentally, please delete it and notify the sender. Although this
message has been
screened for viruses, we cannot guarantee that our virus scanner will
detect all
viruses and take no responsibility for any damage or loss that may be
caused by its
contents.
Received on Friday, 18 November 2005 14:28:20 UTC