Roger,

I've posted here about this schematron validation solution a couple 
times, most recently in response to a question of yours! [1].

Reviewing that post, I see I actually wrote a separate stylesheet to 
generate schematron. That's a traditional QA black box approach. 
Ideally, the mind that creates the schematron should be different from 
the mind that creates the transformation--both would read and interpret 
the transformation requirements independently. I didn't have a QA xslt 
developer, so I just put on different hats to write each stylesheet.

Now, it's something different to provide the provenance of each output 
node through the transformation process. I've been intrigued by this 
idea since studying DSSSL, whose transformation model included the 
following requirement, expressed in elegant ISO-spec-eze as:

"For each node that is created in the result grove, links are created 
from each of the constituent nodes of the node whose transformation 
resulted in creation of the node in the result grove to the created 
node. These links are referred to as /arrows/." (DSSSL, ISO/IEC 
10179:1996, section 11.3 Transform-expression)

I've never been called on to produce such a provenance report, but I 
wonder if you could use an xslt tunnel parameter to collect provenance 
information consisting of the origin node (perhaps the id value, 
generated if necessary), the template call chain, any external or 
generated components, and finally the result node identifier.

Regards,
--Paul

[1] 
https://www.biglist.com/lists/lists.mulberrytech.com/xsl-list/archives/202305/msg00037.html

On 6/29/24 02:16, Roger L Costello costello@xxxxxxxxx wrote:
> Paul Tyson wrote:
>
>> Will your "metadata" output be further machine
>> processed to prove the transformation integrity?
> Ha! That is exactly what I am planning to do! I will do the mapping and verify the mapping.
>
>> Years ago when I was asked to verify my transform
>> was correct, I wrote out a schematron result-document
>> with rules stating what the output should look like.
>> Then I ran the schematron rules against the XSLT output.
>> In your case, you could tell schematron to report not
>> only what was expected, but why.
> Wow! This is terrific! I hadn't thought about generating Schematron as I perform the mapping. Thank you!