Re: [relax-ng] Re: RELAX NG + Schematron

[James Clark <jjc@jclark.com>]

> > Or
> > does the assertion affect whether an element is considered to match the
> > element pattern?
>
> No. Schematron assertions are checked after all the document is parsed.
> As you know, a schematron assertion can potentially access the whole
> document, so I don't think it's possible to use the assertion to affect
> the match.

If you're implementing on top of SAX, that's true.  But since RELAX NG does
not alter the infoset, I don't think there is any conceptual incoherence in
having the assertion affect the match, and I don't think it would be hard to
do this on top of the DOM.

The approach you've taken works well with the way Schematron provides
messages to be given to the user.

For the other approach, it would make more sense to simply have an attribute
with an XPath expression:

<element name="orders" x:require="count(order) > 4">
  <oneOrMore>
    <ref name="order"/>
  </oneOrMore>
</element>

>
> > If the former, what constraints are you imposing to enable
type-assignment?
>
> Right now, none. It's just assuming naively that there is no ambiguity
> in the schema. So it will not work correctly for schemas like:
>
> <choice>
>   <element name="foo">
>     <s:assert test="false"/>
>     <empty/>
>   </element>
>   <element name="foo">
>     <s:assert test="false"/>
>     <empty/>
>   </element>
> </choice>
>
> Where it should reject <foo/>, the current implementation accepts it.
>
> I really want to find a restriction that makes the type-assignment
> possible, but so far I no luck. I think it's very hard to develop an
> algorithm which is complete as well as sound.

By sound you mean if the restriction holds, then type-assignment is possible
(or easy for some definition of easy)? By complete, if type-assignment is
possible, then the restriction must hold? Right?

> So the only hope is to develop a sound algorithm, if not complete.

While completeness is satisfying theoretically, I don't think it's essential
from a practical perspective.

> Are you (or anyone) interested in such a restriction? Is it OK to
> discuss more about this here?

I think it's fine to discuss it here.

In choosing the restriction, I think what's important is that the
restriction is selective, in that it applys only when you use s:assert.
Instead of finding a restriction sufficient to unambiguously assign an
<element> pattern to every element in the instance, we should find a
restriction sufficent to unambiguously unassign a set of s:assert elements
to every element in the instance.

I would be inclined to use the same approach that we had with xsl:key and
xsl:keyRef, namely that there is no path wrt respect to which two different
sets of s:assert elements are applicable.

I think from a practical perspective this is sufficient.  If a user needs to
apply different constraints based on siblings, then they can move the
assertion up the tree to apply to a higher level element and use XPath
predicates to distinguish the different siblings.

James