Cart
[Home] [By Thread] [By Date] [Recent Entries]
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
