Re: cross references

[James Clark <jjc@jclark.com>]

There's another problem with our current syntax.  Suppose I have

<data type="token" key="ns1:foo" keyRef="ns2:baz"/>

There's no way to transform the QNames into ns attributes, as can be done 
with all other uses of QNames.  This is a problem both because it is 
undesirable to force the use of QNames, and because it complicates the 
specification of the language: it is much nicer if one can get rid of 
QNames as part of the transformation into the simple core language, so that 
they don't show up in the inference rules for the semantics. (A simple 
solution to this problem would be to disallow key and keyRef both occurring 
on a single <data> element.)

One possibility for solving the problem raised by Franck would be to use

<key name="xxx">
  <data type="foo"/>
</key>

instead of

  <data type="foo" key="xxx"/>

Similarly add <keyRef>.

The problem then is to specify how <key> determines what base data type to 
use for comparing keys for equality.  We could do something like this:

E; ns |- {}; s =~ p => {}; {}    hasDatatype(E, p, u1, ln1)
-----------------------------------------------------------
E; ns |- {}; s =~ <key name="ln2" ns="u2">p</key>
  => key(u2, ln2, u1, ln1, s, ns); {}

(similarly for keyRef)



------------------------------------------------------------------------
hasDatatype(E, <data type="ln" datatypeLibrary="u">params</data>, u, ln)


---------------------------------------------------------------------
hasDatatype(E, <value type="ln" datatypeLibrary="u">s</value>, u, ln)


         hasDatatype(E, p1, u, ln)
--------------------------------------------
hasDatatype(E, <choice>p1 p2</choice>, u, ln)


         hasDatatype(E, p2, u, ln)
--------------------------------------------
hasDatatype(E, <choice>p1 p2</choice>, u, ln)

etc

Then introduce appropriate restrictions on the content of <key> and 
<keyRef> to ensure that the base datatype is unambiguous. In the normalized 
form, the content of key and keyRef should probably be just a choice of 
<data> and <value>.

I think this is probably a good thing, although I'm concerned that it 
complicates the spec. If we do this, I would argue for not allowing any of:

- a <key> inside a <key>
- a <key> inside a <keyRef>
- a <keyRef> inside a <keyRef>
- a <keyRef> inside a <key>

because this makes things even more complicated.

--On 28 June 2001 00:21 +0900 Murata Makoto <mura034@attglobal.net> wrote:

> Franck Delahaye wrote:
>
>> Now it makes problem to put the key/keyref attribute <data> refered by
>> all attributes, as all these attributes will become potentiel key/keyref
>> attribute.
>
> In your example, you would like to have many keys  (e.g., references
> to <activation>, references to <graph>,...).  But <data ...> is specified
> only once in <define name="fm.id">, and fm.id is referenced repeatedly.
> Where do we specify key=".." and keyref="..."?    Good point.
>
> Please add an issue to the issue list.  > Kawaguchi-san
>
> Cheers,
>
> Makoto
>
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: relax-ng-request@lists.oasis-open.org
>
>