[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
- From: "G. Ken Holman" <gkholman@CraneSoftwrights.com>
- To: "HILLMAN, Tomos" <tomos.hillman@oup.com>,"xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
- Date: Mon, 20 Jun 2016 09:04:31 -0400
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: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.
https://www.avast.com/antivirus
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]