W3C home > Mailing lists > Public > public-sml@w3.org > October 2007

[Bug 4995] Scoping of sml identity constraints (key, keyref, unique)

From: <bugzilla@wiggum.w3.org>
Date: Thu, 25 Oct 2007 16:37:36 +0000
CC:
To: public-sml@w3.org
Message-Id: <E1Il5iC-0003ZG-3K@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4995





------- Comment #4 from sandygao@ca.ibm.com  2007-10-25 16:37 -------
There are a few reasons SML may choose to behave differently from XSDL.
- XSDL was designed to stream well, which is part of the reason why keyrefs can
only look at keys contained in the current sub-tree. Streamability can hardly
be a requirement for SML.
- XSDL only handles a single XML document; SML handles many XML documents.

Comparing the 2 examples given in comment #2, there are a few differences:

1. Separation of concern

In the "scope" approach, the reference only needs to identify where to look for
keys; whereas the "ancestor" approach also requires the reference to know about
how the keys are selected (<select>) and how the fields are identified
(<field>).

2. Copies of the same/similar keys

There may already exist an <xs:key> for the keys in the "students" document. In
bug 4684, we decided that sml:keyref can't refer to xs:key. So an <sml:key>
needs to be added, which is basically a copy of the <xs:key>. The example of
the "ancestor" approach now requires that another similar (same fields but
different selector) <sml:key> needs to be defined for *every* <sml:keyref> to
these keys. This means that there may be n+2 similar key definitions for the
same key concept: 1 for xs:key; 1 for sml:key; one for every <sml:keyref>. This
increases maintenance cost.

3. Performance

Because the "n" <sml:key>s (that are associated with <sml:keyref>s) are
different key definitions, they will be evaluated separately, resulting the
same key constraint being checked n+2 times. The "scope" approach can reuse
keys produced by the single <sml:key>.


I don't think we can deny the above 3 differences. They are advantages of the
"scope" approach. Of course there's associated cost, which is the new "scope"
attribute and semantics around it.

The WG needs to weigh the benefit against the cost, and make an informed
decision.
Received on Thursday, 25 October 2007 16:37:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:56:07 UTC