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: [relax-ng] Re: RELAX NG + Schematron


Good notes on the options here.

Dropping syntax between "syntax(stuff)" was something I pushed in the
eDTD ideas - it has its plus and minus points.

The assert idea also intigrues - I think I need more time to consider
all this and look at the SchemaTron sutff more closely.

Thanks, DW.
Message text written by James Clark
>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
with an XPath expression:

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

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
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.

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

Powered by eList eXpress LLC