Re: Specifying key/keyrefs constraints for Link/XPointer 'bare names'.


Looking for a workaround for this issue (now posted on where it belongs), I think I have found
an implementation problem, though it can also be seen as a way to
understand the XPath rec.

My idea is to use, as it's possible with XSLT/XPATH a unique ID defined
through a minimal DTD.

I have added the following in my document:

<!DOCTYPE library [
<!ATTLIST author id ID #IMPLIED>
<!ATTLIST character id ID #IMPLIED>

and I have tried to use it in my key/keyref:

	<xsd:key name="authorKey">

	<xsd:keyref refer="authorKey" name="book2author">
		<xsd:field>id(substring-after(@xlink:href, '#'))/@id</xsd:field>

Since the id() XPath function returns a nodeset within the document, I
thought this should work... but it silently fails to detect keyref

I think it depends on the interpretation of the XPath rec:

To me, "The id function selects elements by their unique ID" is implying
a reference to a nodeset (and should be valid in a xsd:field) rather
than a function returning a node set...


Reference :

Test case:

Eric van der Vlist wrote:
> Hi,
> I am trying to specify a key/keyref (or id/idref) constraint for a XLink
> which is using the 'bare names' [1] XPointer scheme in the same
> document.
> This means that I'll have a key definition like:
>         <character id="character_Snoopy">
> and a reference like:
>         <character xlink:href="#character_Snoopy" xlink:type="simple"/>
> The problem in both cases (key/keyref or id/idref) is that the "#" needs
> to be added in the xlink:href reference.
> Even with key/keyref, more flexible than id/idref, the keyref must be
> constructed as a path to an existing node and cannot be the result of a
> XPath function (string-after(@xlink:href, "#") would have done the trick
> otherwise.
> Is there any other way to solve my specific case or any chance that we
> could change this in the spec ?
> Thanks
> Eric
> PS: a full XPointer would still be a more interesting case since, it's
> the value of the attribute which should then be interpreted as XPath
> expression...
> [1]
> --
> ------------------------------------------------------------------------
> Eric van der Vlist       Dyomedea          
> ------------------------------------------------------------------------

Eric van der Vlist       Dyomedea              

Received on Saturday, 2 September 2000 07:26:25 UTC