Re: [xml-dev] [Summary] Characterization of Schematron - Usage and Featu

["bryan rasmussen" <rasmussen.bryan@gmail.com>]

> 3. Algorithmic checking
>
> In the above example the algorithmic constraint is: "the election results
> must add up to 100%"
> (i.e., 61 + 24 + 15 = 100).
>
> In general, validity of data in an XML instance document is determined not
> by mere examination or comparison of the data, but requires performing an
> algorithm on the data.
>
>
> Schematron is very well-suited to expressing algorithmic checks.
>
> Note:
>
> "Algorithmic checking" may not be the best name for this category.  Other
> names suggested: "Computed value checking", "Formula checking", and
> "Equation checking".


Actually the above example is not matching what I was thinking of as
an algorithmic check. It is more like a co-constraint, all the
elements in the example have data the value of which is dependent on
other data.

The algorithmic check is more along the lines of:

A textnode has data that can be validated using a well-known algorithm
such as a modulus 10 function. As such it can not be done via
Schematron, however in most actually occuring markup situations we do
not have just a textnode, we have a textnode that has some other
information represented by the markup pertinent to that textnode, such
as  this textnode that can be validated via the modulus 10 function is
a social security number, as such the algorithm can be applied because
we know when we have to stop, we do not have to loop until we stop.

Basically this is something one might like to see in a datatype
defining language, and in fact if I understand my cursory scanning of
the DSDL Datatype Library language the same method could be used to
define datatypes conforming to a particular algorithm (can anyone
correct me if I'm wrong on this?)

This, as opposed to your example, is actually not something Schematron
is especially good at, it is something of a Stupid Schematron trick
given that writing these by hand is onerous and it is probably best to
either autogenerate the expression or move up a level to do the check.
 This is actually why I brought it up because I was pretty sure there
would be very few people that were using Schematron to do stuff like
check that something purporting to be an EAN location number actually
conformed to the algorithm for checking EAN location numbers.

That said I think that using Schematron for this while not optimal
points to some possible benefits, the fact that it is declarative and
obviously easier for a program to analyse. There is obviously no
halting problem in the schematron assertion I sent before.

Cheers,
Bryan Rasmussen