OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
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
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
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:gkholman@CraneSoftwrights.com |
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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS