> occasionally 28 or 29. Does this refinement mean you are doing something of
> a fundamentally different nature? I think not. It does mean that you've
> crossed the limits of what can be done with a grammar-based approach, but
> surely we should make it as easy and seamless for people to cross that
> boundary as we can?

Perhaps I was a bit vague in my assertion of "fundamentally
different".  Yes, of course, it's valid to think of your the extension
in your example as being wholly inside the problem domain.  It's still
validation, of course.  I was hoping to hint that since assertion
based rules are not necessarily bound to any one point in a grammar,
then we should try to keep them as separate as possible.

In your example, it's easy to tie that assertion to the month
complex-type.  What if we have, however, a rule like

//@bodyType='Regular'/descendant::node()/@color =
/Factory/Chasis[@bodyType='Regular']/Colors/Color

under which node would we place the assertion declaration?  In plain
english I want to make sure for every part for a regular body that
needs a color, we have a Chasis station that can supply that color.
We could define an enumeration every color attribute, but the
manufacturer wants catalytic doodles in different colors than exhaust
spinners.  We also want to make sure the Chasis people don't retire a
color thats needed for the rear spoiler bug guard.  Finally, we
should have this failure report to the user to go call Color
management so they don't have to parse the rule.  Since we have
factories in several different countries we have stylesheets that
specify the text in the correct language.  Whew!

So where does this assertion pertain to in the grammar?

I'd argue that since such a relationship is non-trivial for many real
world rules, we should keep the assertion declarations separate from
the grammar specification, e.g. sch:pattern could be a sister element
to top level types, i.e. under xs:schema or perhaps a new top level
element  xs:patterns , but not else where. (this may be fairly small
point to argue, i know)

Why even put them in the same validation document then?  Because it's
incredibly convenient to do so, and as you pointed out, though it's
out of the bounds of the grammar-based approach, it's still terribly
relevant to having a valid document.

IMHO assertion validation is different enough to not be defined under
the same sub-tree, but relevant enough to be in the same validation
document.  If it meant getting Schematron included as standard in XML
Schema, though, I'd be happy to concede on this point.

~Chris