Re: [jats-list] Can an Editor Write Schematron?

["Wendell Piez wapiez@xxxxxxxxxxxxxxx" <jats-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

Gareth,

This is totally doable, but you end up wanting an enhanced Schematron, that
carries code numbers per rule (possibly structured in some way) for binding
points, plus also documentation. There are actually two sets of information
that need to be represented on both sides (Schematron source and
spreadsheet in this case): the Schematron behavior (including the messaging
it emits); and its rationale and "flagging" (such as those controlled IDs).
The latter can be represented in the Schematron in an extension namespace.
Then the Schematron has a fairly rich data set you can externalize in that
spreadsheet or in other ways for the consumption of people who need to see
and validate the "intent" of the logic, without its implementation.

I've heard tell of this approach working well producing HTML reports (for
both rule set management, and validation reports that link to them), not
worrying about spreadsheets.

In the ideal scenario, of course, all this is also aligned with test sets
(see the JATS-Con articles by Sasha Schwartzman and Vince Lizzi, at least),
and subject matter experts can sometimes validate test sets even when they
can't write the XPath. So you get an extra vector: SME confirms that both
rationales, and test examples, are correct; this gives the developer
something external to test the XPath against. When it works, an
XPath-literate third pair of eyes looks at it all together (and makes
improvements), eh voila.

In a somewhat similar approach, the documentation/metadata per rule is not
embedded in the Schematron, but rather the Schematron itself is generated
by machine from a language optimized to provide for support of certain
kinds of rules ... another topic.

Cheers, Wendell




I have heard tell of this working well, but with HTML reports rather than
spreadsheets.

On Thu, Feb 11, 2021 at 6:02 PM Gareth Oakes goakes@xxxxxxx <
jats-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:

> Codifying the logic as English statements in a spreadsheet seems like a
> good approach. I wonder if you can "sync" this with the Schematron by
> generating English language statements from the Schematron asserts/reports?
> That way once the programmer interprets the latest spreadsheet they can
> regenerate the spreadsheet from the Schematron file, ready for the next
> time an editor wants to update the spreadsheet. This gives a handy point of
> reference for the current logic as well as a clue to the type of language
> (and thought process) the editor should be using.
>
> // Gareth Oakes
> // VP Content Technologies, GPSL
> // www.gpsl.co
>
> o;?On 12/2/21, 08:55, "Debbie Lapeyre dalapeyre@xxxxxxxxxxxxxxxx" <
> jats-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>
>     Flip answer: Yes if they know XPath.
>
>     More useful answer:
>
>     1) They are more likely to RUN Schematron, as set up
>     by programmers, than to write it. Whole test suites
>     can be set up for them to run single-click.
>
>     2) But, they can also SPECIFY Schematron (in a natural language such as
>     English) IN A SPREADSHEET that tells the programmers what to check and
>     what error message the Editors want back.
>
>     The editors are in charge of the requirements document (the
> spreadsheet).
>     The programmers are in charge of interpreting those requirements in
>     Schematron and of updating the spreadsheet to say which module(s)
>     check each requirement.
>
>     Some basic spreadsheet logic of giving each request a unique
>     number, error severity (such as editorial error, XML error | human must
>     look at this one, caution, fatal, make up whatever categories you
>     think are useful), status, QA or management signoff flag, whatever
>     you need is useful.
>
>     This is a very handy system that works well for many. Most
>     Editors know spreadsheets. There are no pointy brackets in sight.
>     It has the additional psychological advantage that the Editors
>     feel that the programmers are working for them, finding the
>     errors Editors want fixed, not imposing rules from above.
>
>     --dal
>
>
>     > On Feb 11, 2021, at 5:30 PM, Gareth Oakes goakes@xxxxxxx <
> jats-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>     >
>     > Sorry to jump in but that is an interesting thought. I suspect your
> average PE would get stuck on the fact that you need to know XPath and be
> quite familiar with the JATS schema in order to create good Schematron
> assertions or reports. I wonder if there is a UI solution that would help
> in this case though? I'm not aware of one but am interested to hear from
> others. It would sure save the trouble of having an XML person come in to
> define and maintain those basic editorial rules.
>     >
>     > I think the pre-requisites for Schematron are experience with XML,
> good knowledge of XPath, and working knowledge of the schema you are
> writing rules against.
>     >
>     > // Gareth Oakes
>     > // VP Content Technologies, GPSL
>     > // www.gpsl.co
>     >
>     > On 12/2/21, 06:44, "Charles O'Connor coconnor@xxxxxxxxxxxx" <
> jats-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>     >
>     >    Hi Liam,
>     >
>     >
>     >
>     >    When the Schematron course comes together, please ping me off
> list.
>     >
>     >
>     >
>     >    I did a webinar yesterday on our (Aries) XML-through production
> workflow, which includes the ability to configure a task to run Schematron.
> Question from a participant was, "This Schematron thing sounds cool, but is
> it something the average production editor could write?"
>     >
>     >
>     >
>     >    My answer was that a somewhat ambitious one certainly could.
> There may also be interest among others at Aries.
>     >
>     >
>     >
>     >    Also, let me know whether there are prerequisites beyond a basic
> knowledge of what XML is and how it works.
>     >
>     >
>     >
>     >    Thanks,
>     >
>     >    Charles
>     >
>     >
>     >
>     >    -----Original Message-----
>     >
>     >    From: Liam R. E. Quin liam@xxxxxxxxxxxxxxxx <
> jats-list-service@xxxxxxxxxxxxxxxxxxxxxx>
>     >
>     >    Sent: Wednesday, February 10, 2021 2:55 PM
>     >
>     >    To: jats-list <jats-list@xxxxxxxxxxxxxxxxxxxxxx>
>     >
>     >    Subject: [jats-list] [ANN] XSLT 3 training - dates for February,
> March, April 2021
>     >
>     >
>     >
>     >    *** External email: use caution ***
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >    I'll be running XSLT 3 training on
>     >
>     >    * 23rd, 24th, 25th of February,
>     >
>     >      (likely in CET times, e.g. 09:30-15:00 depending on numbers of
>     >
>     >    people)
>     >
>     >
>     >
>     >    * 23rd, 24th, 25t of March,
>     >
>     >    * 27th, 28th, 28th of April
>     >
>     >
>     >
>     >    The courses are live video (not pre-recorded); classes are
> limited to eight people at a time. Shoes optional :)
>     >
>     >
>     >
>     >    There's a course overview at
>     >
>     >    https://www.delightfulcomputing.com/
>     >
>     >
>     >
>     >    In addition, i know you've been missing XML Prague, so a
> Schematron course is in the works.
>     >
>     >
>     >
>     >    The single most important thing to me in teaching is empowerment:
>     >
>     >    helping people to see how to find their own answers, and to go
> out into the world and solve new problems.
>     >
>     >
>     >
>     >    Liam
>     >
>     >
>     >
>     >    PS: there's some flexibility in the dates, and the time of day
> can be adjusted to meet your needs, depending on who is participating.
>     >
>     >
>     >
>     >
>     >
>     >    --
>     >
>     >    Liam Quin, https://www.delightfulcomputing.com/
>     >
>     >    Available for XML/Document/Information Architecture/XSLT/
> XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
>     >
>     >    Barefoot Web-slave, antique illustrations:
> http://www.fromoldbooks.org
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>     >
>
>     ================================================================
>     Deborah A Lapeyre              mailto:dalapeyre@xxxxxxxxxxxxxxxx
>     Mulberry Technologies, Inc.      http://www.mulberrytech.com
>     17 West Jefferson Street         Phone: 301-315-9631 (USA)
>     Suite 207                        Fax:   301-315-8385
>     Rockville, MD 20850
>     ----------------------------------------------------------------
>     Mulberry Technologies: Consultancy for XML, XSLT, and Schematron
>     ================================================================
>
>
>
>

--
...Wendell Piez... ...wendell -at- nist -dot- gov...
...wendellpiez.com... ...pellucidliterature.org... ...pausepress.org...
...github.com/wendellpiez... ...gitlab.coko.foundation/wendell...