Re: [xml-dev] Implement data rules in application code?

curly brackets instead of angled ones.

On Mon, Apr 10, 2017 at 3:00 PM, yamahito <yamahito@gmail.com> wrote:

Really isn't Schematron itself just "the use of application code to enforce data constraints"?

The advantage of Schematron is that it is reusable, transferable less opaque etc. to abstract the expression of those constraints: might there be another compelling reason why a different type of application code offering similar advantages might be preferable in some cases?

T

On Mon, 10 Apr 2017 at 19:47 Michael Kay <mike@saxonica.com> wrote:
An XSLT stylesheet that exists solely for the purposes of data validation doesn't look very different from a Schematron module written to perform the same function. Both are essentially a list of rules and actions: the only difference is that the schematron version is written in a language that is slightly more specialised to the task.

What's a bad idea is not using XSLT for validation, but mixing data validation and data processing in the same module.

So it rather depends what you mean by "application code".

Michael Kay
Saxonica

On 10 Apr 2017, at 18:05, Costello, Roger L. <costello@mitre.org> wrote:

Hi Folks,
Lately, to my surprise, I have been hearing more and more people advocate the use of application code to enforce data constraints (data rules). Particularly the complex data rules you might expect to find in Schematron. Their argument, presumably, is that for most domain experts and business people, data rules such as the following are gibberish:
<sch:pattern id="Knowledge-about-radio-stations">
    <sch:rule context="GeographicArea">
        <sch:let name="stations" value="RadioStation"/>
        <sch:assert test="
            every $s1 in $stations, $s2 in $stations satisfies
                if (pred:Disjoint($s1, $s2)) then
                    number($s1/band) ne number($s2/band)
                else true()
            ">
            Radio stations broadcast on different frequency bands (within an area).
        </sch:assert>
    </sch:rule>
</sch:pattern>

Since they are gibberish, you might as well have the developers implement the rules in application code. Out of sight, out of mind.

I guess that’s their argument.

I thought the world had moved beyond such thinking, years ago. I thought that everyone had come to the agreement that burying data rules in application code is a bad idea.

So what happened?

Did the world suddenly get amnesia? Did the experience from the last 20 years reveal that expressing data rules in text, declaratively didn’t work out as desired?

/Roger