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

> It's the strongest and least ad-hoc restriction on <key> and <keyRef> that 
> we have been able to find so far. If you have a stronger and less add-hoc 
> one, I would be delighted to hear it.  If you perceive it to be weak and 
> ad-hoc, then I would suggest that a constructive response is to try to make 
> it stronger not weaker.

A promising approach is to combine recent papers (most of which are
coauthored by Wenfei Fan) and my ambiguity detection algorithm.
However, I think this should be addressed in another specification after 
RELAX NG is finished.

> I am all in favour of clear statement that this is not intended to be a 
> generalized solution.

Here we agree.

> However, I see no incompatibility between such a 
> statement and our current approach.

Here we do not.  I think that your proposal is a back-handed mechanism 
for handling paths of arbitrary lengths.
> From a practical perspective, I believe what we have is a considerable 
> improvement over ID/IDREF.

How should application progammers find out paths to keys?  Path expressions 
are implicitly represented in your proposal, and application programmers have 
to find out.  I think that this is a significant burdern.
> I agree that inference rules are not absolutely required.  However a fair 
> comparison of the relative complexity of two approaches requires that they 
> be expressed with similar levels of formality.

What I think is fair comparison is not the based on the length of
formal inference rules.  If people find it easy, it is easy.  Who 
in this TC understands 7.4?

> As I understand it, you propose that for determing key-ambiguity we should 
> only consider
> 1. The name of the attribute or element containing the key, and
> 2. The name of its parent element
> in other words the last 2 segments on the ancestry path.  Why consider 2 
> segments only? Why not 1? Why not 3? Why not 42?  It's just so arbitrary. 

Because this is compatible with XML DTDs.  As you have argued, we are
trying to introduce a simple mechanism which is a bit better than

> Once you have more than one, you have almost all the implementation 
> complexity of the current approach, because you have to consider 
> intersection of name classes.

I do not think so.  You have to enumerate paths of arbitrary lengths
and still have to avoid infinite loop.  

> Your approach would yield an ambiguity in the following case:
> <ns1:foo>
>   <bar>
>     <baz>key</baz>
>   </bar>
> </ns1:foo>
> <ns2:foo>
>   <bar>
>     <baz>not key</baz>
>   </bar>
> </ns2:foo>
> where ns1 and ns2 are separate namespaces and baz in ns1 is a key but baz 
> in ns2 is not.  I think that's quite wrong. Personally, I don't much care 
> for this style of using namespaces, but there are plenty of people who do.

I don't care this style either.  Those who care should should wait for 
a different specification for identity constraints or design their own.



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

Powered by eList eXpress LLC