Re: [relax-ng] Implementation of restrictions on interleave

[James Clark <jjc@jclark.com>]

The object of the third through fifth bullets is to ensure that for any 
pattern <interleave>p1 p2</interleave> there is no possibility of a string 
matching both a leaf-pattern in p1 and a leaf-pattern in p2 (by leaf 
pattern I mean <data> or <value> since <text> and <list> cannot occur in 
<list>).   To guarantee no possibility of such a match, we have to ensure 
that there is no string that can match no matter what the context is.

If we allow p1 and p2 to contain leaf-patterns with different datatypes, 
then there is no way to implement this restriction, because datatype 
libraries provide no way to compare the sets of strings that might be 
matched by different datatypes.  Similarly there is no way to determine 
whether two <data> elements with different parameters overlap.  But if we 
constraint all <data> elements to have the same datatype and same 
parameters, then if a <data> element occurs in both p1 and p2, the 
interleave pattern will necessarily fail to match the restriction. The 
remaining case is something like

<interleave>
  <data type="token">
    <param name="pattern">[a-z]+</param>
  </data>
  <value type="token">#none</value>
</interleave>

We could almost allow this except for one problem I will discuss below, 
however it's easier to simply disallow list//interleave//data.

If we disallow data and we require consistent datatypes, is it possible to 
check the restriction in the first paragraph? The answer is yes, because 
datatypeEqual is an equivalence relation (see 6.2.8).  Suppose we have a 
pattern <interleave>p1 p2</interleave> and suppose <value type="t" 
datatypeLibrary="d" ns="n1">s1</value> occurs in p1 with context c1 and 
<value type="t" datatypeLibrary="d" ns="n2">s2</value> occurs in p2 with 
context c2.  Suppose we have a string s3 and a context c3 such that s3 
matches both of the value elements wrt c3.  That means that we have

datatypeEquals(t, d, s3, c3, s1, context(n1, c1))

and

datatypeEquals(t, d, s3, c3, s2, context(n2, c2))

Thus by applying the rules (datatypeEqual symmetric) and (datatypeEqual 
transitive) we obtain:

datatypeEqual(t, d, s1, context(n1, c1), s2, context(n2, c2))

Therefore in order to check that the restriction in the first paragraph 
applies it is sufficient to ensure there is not a <value> pattern v1 
occurring in p1 and <value> pattern v2 occurring in p2 such that the 
strings in v1 and v2 compare equal using the normal contexts of v1 and v2 
(i.e. the context used for comparing the equality of each of v1 and v2 is 
the context that would be used when each of v1 and v2 is matched against a 
string in the instance).  The reason I didn't state it that way is because 
it is hard without formalism to state the context used for comparing the 
values and also because I wanted to emphasize the similarity with the 
element/attribute/text case.  It would probably be helpful to add a note 
after the fourth bullet saying that this restriction together with the fact 
that datatypeEqual is symmetric and transitive allows the third bullet to 
be checked simply by comparing the <value>s in p1 and p2 for equality.

Going back to <data>, we don't have any rule at the moment that says that 
datatypeAllows is consistent wrt to datatypeEqual (i.e. if two things are 
datatypeEqual, then either both should be allowed or neither should be 
allowed).  If we had this, I think we could allow one operand of the 
interleave to contain <value> while the other operand contained <data> such 
that the <value> was not allowed by the <data>, but I don't think this is 
worth it.

--On 25 October 2001 00:08 +0900 MURATA Makoto <EB2M-MRT@asahi-net.or.jp> 
wrote:

> James Clark wrote:
>
>> I implemented the proposed restrictions on interleave, including
>>
>> - restrictions on element names for interleave not inside list
>> - restriction on <text/> for interleave not inside list
>> - restriction on <value/> for interleave not inside list
>> - disallowing list//interleave//data
>
> Did you implement the third bullet in the itemized list in 7.4?
>
> 	there must not be a string that, with respect to some context, matches
> 	both a value pattern occurring in p1 and a value pattern occurring in p2;
>
> If so, how did you implement "with respect to some context"?
>
> I am afraid that I do not fully understand the reasons behind the third
> and forth  item in this itemized list.  Could you elaborate?
>
> Cheers,
>
> Makoto
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>