Hi,

On Mon, 2005-09-26 at 20:21 +0100, Michael Kay wrote:
> > 
> > A strategy which would follow this assumption could look like
> > (but only semantically, since this is not streamable):
> > 
> > 1. Build the sum of all qualified node sets of all scope elements
> >   of the referenced IDC key/unique definition in the
> >   descendant-or-self axis, starting with a scope element
> >   of the keyref.
> > 
> > 2. Remove all nodes with identical key-sequences from this set.
> > 
> > 3. Find a match for the key-sequence of a qualified node of the keyref
> >   in this set.
> > 
> > 4. If no match was found then we get an error, since either
> >   no matching key-sequence existed, or a duplicate existed and
> >   was removed.
> > 
> > Does this make sense?
> 
> I think this is essentially what Saxon is doing today (except that I found a
> bug in the handling of <xs:selector xpath="."/> which is proving very hard
> to fix without stopping everything else from working!). I assume you mean in
> (2) that if you find 2 duplicates, you remove both. (It's nice however to

Yes.

> give different errors for "no match" and "more than one match".) But what
> worries me is that the way the rule is phrased, removal of duplicates
> depends on whether they bubbled up from a descendant, or were found at the
> top level. I can't see any reason why anyone would want to specify it that
> way, but that's not necessarily a good way of trying to work out what
> this absurdly complex spec actually says.

:-)

Yeah, I now noticed that the current wording of the spec seems to be
inconsistent if taking the effects of total elimitation into account.
Here an example:

key-2.xsd
---------
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">

  <xsd:element name="SECTION">
    <xsd:complexType>
	  <xsd:sequence>
	    <xsd:element ref="SECTION" minOccurs="0" maxOccurs="2"/>
        <xsd:element name="DEFINITION" minOccurs="0" maxOccurs="5">
          <xsd:complexType>
            <xsd:attribute name="term" type="xsd:string"/>
          </xsd:complexType>
        </xsd:element>
        <xsd:element name="TERMREF" type="xsd:string" minOccurs="0"
maxOccurs="5"/>					
      </xsd:sequence>
    </xsd:complexType>

    <xsd:key name="defKey">
      <xsd:selector xpath="DEFINITION"/>
      <xsd:field xpath="@term"/>
    </xsd:key>

    <xsd:keyref name="termRef" refer="defKey">
      <xsd:selector xpath="TERMREF"/>
      <xsd:field xpath="."/>
    </xsd:keyref>
  </xsd:element>
</xsd:schema>

key-2.xsd
---------
<SECTION xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:noNamespaceSchemaLocation="key-2.xsd">

  <SECTION>
    <SECTION>
      <DEFINITION term="zappa"/>
    </SECTION>
    <SECTION>
      <DEFINITION term="zappa"/>
    </SECTION>
    <!--DEFINITION term="zappa"/-->
  </SECTION>
  <TERMREF>zappa</TERMREF>	

</SECTION>

This will produce an error, since the entries for "zappa" are
eliminated when merging them into the node-table of the 2nd SECTION.
The node-table is empty.

On the other hand, if we uncomment the 3rd DEFINITION, this one
gets perfectly propagated to the 1st SECTION and the keyref should be
happy (and XSV 2.10 is).

So this would produce a mechanism where the success of keyref-
resolution is dependant on a specific constellation of the keys in
the tree - hopefully this is not intended.
I guess this is comparable to your description of the problem, but
demonstrated with the "total elimitation" effect.

Regards,

Kasimier




From bob@n... Tue Sep 27 03:31:05 2005
Received: from wiggum.w3.org ([128.30.52.23])
	by frink.w3.org with esmtp (Exim 4.50)
	id 1EK6BN-0005z0-8j
	for x