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

["Peter Hunsberger" <peter.hunsberger@gmail.com>]

On 1/24/07, bryan rasmussen <rasmussen.bryan@gmail.com> wrote:

<snip/>

> 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.
>

Using XSLT 2.0 and xPath 2.0 with Schematron can make this kind of
thing more-or-less trivial for a lot of cases... :-)

-- 
Peter Hunsberger