Re: [xml-dev] The awesome power of Schematron: using user-defined XSLT functions in Schematron

At 2016-06-20 08:17 +0000, HILLMAN, Tomos wrote:
>Whilst I agree with Ken's assertions as an important caveat, I also think
>that there's something important to be recognised in Roger's enthusiasm
>(which ought to extend to XSLT features like keys as well as user defined
>functions).

ISO/IEC 19757-3 Annexes C and H are normative and they state that the 
XSLT key element may be used, so a non-XSLT implementation would, I 
think, still have to support it.  My concern was only with 
user-defined functions.

>XSLT implementations may not be the best fit for your needs, but they do
>lend huge expressive power, are widely supported by editing tools and
>CMSs, and are easy to implement (particularly in environments where you
>are already performing large XSLT transforms).

I grant all that, Tomos, of course!  The expressive power is what is 
so very attractive.  But its popularity may become its handicap if 
systems get bogged down during execution.

In my UBL (ISO/IEC 19845) circles, it is very attractive to express 
constraints using Schematron, but UBL is becoming very popular.  It 
is being legislated in some places and becoming the "go to" 
electronic business document standard in many, many more.  The burden 
of supporting Schematron becomes a discussion point.  The burden of 
deploying an XSLT-based Schematron then becomes the next discussion point.

This is top-of-mind for me as we begin our work on UBL 2.2 this month.

>We run a centralised schematron service (rightly or wrongly, it uses an
>XSLT implementation - as our team is responsible for writing the
>schematron rather than running the server, I'm happy about it)

Are you prepared for the server team to come back to your team 
regarding performance and capacity?

>, and there
>are certainly some advantages to doing so (we can be sure the schematron
>is relatively up to date, gather statistics, etc).  However I do wonder if
>the portability of schematron means we ought to be considering a more
>distributed model - at the very least I can see the advantages in our
>suppliers, capturers and (one day soon) authors having access to errors as
>they capture/write content, reducing our own QA service to a confidence
>check.

I'm curious about the "distributed model" ... what more can you say 
about that publicly?  Is it something I need to consider for UBL 2.2?

. . . . . . . . . Ken


--
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Streaming hands-on XSLT/XPath 2 training @US$45: http://goo.gl/Dd9qBK |
Crane Softwrights Ltd. _ _ _ _ _ _ http://www.CraneSoftwrights.com/x/ |
G Ken Holman _ _ _ _ _ _ _ _ _ _ mailto: |
Google+ blog _ _ _ _ _ http://plus.google.com/+GKenHolman-Crane/posts |
Legal business disclaimers: _ _ http://www.CraneSoftwrights.com/legal |


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus