OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: Alternative approach for key/keyref


I think path-expression-based approaches to key/keyRef constraints are very 
useful, and I am glad you have figured out how to ensure consistency 
between such RELAX NG and such constraints at least as far as datatypes are 
concerned.  Am I right in thinking there are other consistency issues apart 
from datatypes?

The question arises of how such path-expression-based approaches fit in 
with RELAX NG.  With a path-expression-based approach, elements and 
attributes can play three roles:

a) They can be the root of a subtree within which some set of keys is unique

b) They can be the target (the common ancestor of the various fields): the 
object that conceptually is identified by the key

c) They can be the individual fields that together identify a particular 
target

Now W3C XML Schema uses paths for (b) and (c) but not for (a).  The root of 
the subtrees are identified by adding <key> and <keyRef> elements to the 
element declarations for the elements that serve as root.  I think this is 
not such a good approach.  It makes it harder for applications to identify 
which elements and attributes are serving as keys: you cannot just give the 
applications the paths; instead they need a PSVI from the key/keyRef 
validator.  Another problem with W3C XML Schema is that they have 
hierachichal keys but don't have hierarchichal references. My gut feeling 
is that supporting hierarchichal references is made harder by not using 
paths for (a).

I believe that a path-based approach should use paths for all of (a), (b) 
and (c).  However, if a key/keyRef constraint languages uses paths for all 
of (a), (b) and (c) there is no need for it to be syntactically integrated 
into the grammar.  The specification of the key/keyRef constraints can be 
syntactically completely separate.  Semantically it can't be completely 
separate because of issues of consistency, and because probably the 
key/keyRef constraints should use the datatypes specified in the grammar.

I think syntactically a key/keyRef based language will likely have a very 
different flavour to RELAX NG.  It is very natural to use a XPath-style 
syntax for paths. XPath has its own way of specifying name classes (*, 
foo:*) which are different from those used by RELAX NG.

This suggest to me that the right approach is to have a "RELAX Keys" schema 
that specifies key/keyRef constraints using paths  and points to or 
includes a RELAX NG grammar (or maybe the binding between a RELAX Keys 
schema and a RELAX NG grammar could be done with RELAX Namespaces).

What does this imply for the key/keyRef facility in RELAX NG at the moment? 
I don't believe we should get rid of it.  I believe RELAX NG needs to have 
built in at least ID/IDREF functionality. I think people can very easily 
migrate from ID/IDERF to our keys; I think the migration from ID/IDREF to a 
path-based approach is much harder for users.  Our approach gains 
significant ease of use by being syntactically integrated in the grammar. 
Section 7.4 looks long and complicated because it's spelling everything out 
formally and rigourously with no hand-waving.  Even if we simplified it to 
be closer to ID/IDREF (by for example not allowing keys to have separate 
symbol spaces), 7.4 would not be much simpler.

There are two things I think we should consider doing:

1. Adding a note explaining that our key/keyRef facility is intended as a 
modest, very easy to use increment on ID/IDREF not as a comprehensive 
solution for key/keyRefs and that more comprehensive solutions can be 
layered on top of RELAX NG.

2. Possibly renaming key/keyRef to something else.  Leave the name 
key/keyRef free for future, more comprehensive path-based approaches. 
Perhaps use a term closer to ID/IDREF.  I think

<id>
  <data type="token"/>
</id>

is quite natural. Using "name" as the name of the attribute indicating the 
ID symbol doesn't seem to fit very well with <id>, <idref>.  Maybe one 
could use

<id class="...">...</id>

Such a "class" attribute should probably be optional.

James













[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC