W3C home > Mailing lists > Public > xmlschema-dev@w3.org > September 2000

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

From: Eric van der Vlist <vdv@dyomedea.com>
Date: Sat, 02 Sep 2000 13:27:25 +0200
Message-ID: <39B0E41D.9F122F6@dyomedea.com>
To: xmlschema-dev@w3.org

Looking for a workaround for this issue (now posted on
www-xml-schema-comments@w3.org 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] http://www.w3.org/TR/xptr#bare-names
> --
> ------------------------------------------------------------------------
> Eric van der Vlist       Dyomedea                    http://dyomedea.com
> http://xmlfr.org         http://4xt.org              http://ducotede.com
> ------------------------------------------------------------------------

Eric van der Vlist       Dyomedea                    http://dyomedea.com
http://xmlfr.org         http://4xt.org              http://ducotede.com
Received on Saturday, 2 September 2000 07:26:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:14:47 UTC