W3C home > Mailing lists > Public > www-xml-schema-comments@w3.org > July to September 2000

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

From: David Beech <David.Beech@oracle.com>
Date: Tue, 05 Sep 2000 17:48:56 -0700
Message-ID: <39B59478.F28DEB98@oracle.com>
To: Eric van der Vlist <vdv@dyomedea.com>
CC: www-xml-schema-comments@w3.org
Eric,

Thanks for your comment.

The xlink:href attribute can be given the simple type uriReference 
(XML Schema part 2: Datatypes 3.2.9) which "may be absolute or
relative, and may have an optional fragment identifier."  Doesn't
this do what is needed?

keyref, like idref, is only provided to support simple value matching,
and there doesn't seem to be any need to stretch it for a special case
when the uriReference type is a good fit with href in general.

Hope this solves the problem.

Thanks,

  David

"Henry S. Thompson" wrote:
> 
> Eric van der Vlist <vdv@dyomedea.com> writes:
> 
> > 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 ?
> >
> > 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
> 
> This is an interesting case, which makes me wonder if we should
> revisit the decision to require the XPath expression specifying key
> fields to evaluate to an element or attribute node -- anybody remember
> what the argument was on this point?
> 
> ht
> --
>   Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
>           W3C Fellow 1999--2001, part-time member of W3C Team
>      2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
>             Fax: (44) 131 650-4587, e-mail: ht@cogsci.ed.ac.uk
>                      URL: http://www.ltg.ed.ac.uk/~ht/
Received on Tuesday, 5 September 2000 20:53:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:49:53 UTC