[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [relax-ng] Re: RELAX NG + Schematron
> > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC