Right. In the simple case (like this one), interleave delivers “one of each of these things in any order”. Thus the content model ( a, b, c ) matches <a/><b/><c/> and nothing else. The content model ( a & b & c ) matches any one of <a/><b/><c/> <a/><c/><b/> <b/><a/><c/> <b/><c/><a/> <c/><a/><b/> <c/><b/><a/> The content model ( a | b | c ) matches any one of <a/> <b/> <c/> Since there is no order, I suppose it is reasonable to say order does not matter. But you can repeat any of these content models, of course, the most interesting one being that last one, because a) it gives you quite a different result, and b) we do it all the time. The content model ( a | b | c )* matches any one of <!-- no element --> <a/> <b/> <c/> <a/><a/> <b/><a/> <c/><a/> <a/><a/><a/> <b/><a/><a/> <c/><a/><a/> <a/><a/><a/><a/> <b/><a/><a/><a/> <c/><a/><a/><a/> <a/><a/><a/><a/><b/> <b/><a/><a/><a/><b/> <c/><a/><a/><a/><b/> <a/><a/><a/><a/><b/><a/> <b/><a/><a/><a/><b/><a/> <c/><a/><a/><a/><b/><a/> <a/><a/><c/><a/><b/><a/> <b/><a/><c/><a/><b/><a/> <c/><a/><c/><a/><b/><a/> etc. So this kind of content model is not appropriate for the constraint we want here — only one of each element, max (it makes no sense to have 2 <history> elements describing a single mss) — unless paired with Schematron as per the Takeda Strategy. My points in my previous post are 1. I think we should have an explicit policy (in TCW 20 or whatever it is) about when we write the content model out longhand and when we make life easier on ourselves (and future maintainers) by invoking the Takeda Strategy. 2. That policy should say we write out the content model for 2–4 particles, and use a “single grouping and or-pipes and one repetition indicator” with added Schematron for cases of 5+ particles. The sequelae of that 2nd idea is that for the current ticket we should employ a content model that lists the 4 particles out longhand (which I have already done in a branch) unless it turns out that a) the MS-SIG really wants <msFrag> and <msPart> to intermingle with the rest, and b) they convince us that is a good idea. In that case we have a grouping of 6, not 4, particles, and we should invoke the Takeda Strategy. Note, BTW, that the content model ( msContents? & physDesc? & history? & additional? & msPart* & msFrag* ) is a little more complicated than those discussed above. You might expect (well, at least I might have expected) that the <msPart>s in documents that match this content model would all have to be siblings of one another. But they don’t. In RELAX NG the <msPart>s and <msFrag>s can appear intermingled among the <physDesc>, <history>, etc. HTH. ________________________________ This is a question about interleave `&` that I raised last week during our meeting, but I don’t remember the answer. You wrote in the last comment on the ticket a tidy explanation of RNG interleave `&` as: “ (Reminder: using the ‘&’ means that each particle is required (although if it has a ‘?’ or a ‘*’ it may occur only 0 times), but that order is not important.)” And you also (a little earlier) point out that perhaps what’s needed for this ticket is something like: ( msContents? & physDesc? & history? & additional? & msPart* & msFrag) Here is my question: Is interleave necessary to express this if order does not matter? Can you express the above even more flexibly with just a single grouping and or-pipes and one repetition indicator: ( msContents | physDesc | history | additional | msPart | msFrag)* The reason not to do that may be the need for `?` constraints on most of the items, but I did want to check to see if it might work to process paired with Schematron as discussed for the Takeda strategy. I guess I am asking, what does interleave deliver, and if an even more flexible content model is appropriate?