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

Hi,

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 book id ID #IMPLIED>
<!ATTLIST character id ID #IMPLIED>
]>

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

	<xsd:key name="authorKey">
		<xsd:selector>author</xsd:selector>
		<xsd:field>@id</xsd:field>
	</xsd:key>

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

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

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...

Eric

Reference :

http://www.w3.org/TR/xpath#function-id

Test case:

http://www.dyomedea.com/tests/xmlschema/library5.xml
http://www.dyomedea.com/tests/xmlschema/library5.xsd
http://www.dyomedea.com/tests/xmlschema/library5-xlink.xsd

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