Activity for MorganaXProc-IIIse
-
xml-project.com modified ticket #212
Error running <p:unarchive> on very large file (800MB)
-
Thank you, Mark.
-
Mark Dunn posted a comment on ticket #212
Thanks very much Achim, we will try this. I think we can close the ticket as resolved.
-
Given this constraint and the nature of the package content, would it still be worth switching up to 1.7.2? I can also reqest an increase to the size of java.io.tmpdir I think you need to increase the size of java.io.tmpdir: If you do not use an exclude- or include-filter on p:unarchive, all entries associated with Binary content-types will be written to this folder. So you need enough space for them. Switching to 1.7.2 makes most sense, if you have more than on p:unarchive or an iteration over a...
-
Thanks Achim, this sounds like the right explanation. Most of the package is a few videos, each of 100-200MB in size. The java.io.tmpdir has a maximum capacity of 2GB so it's likely that this was getting full at the time this job was run. Given this constraint and the nature of the package content, would it still be worth switching up to 1.7.2? I can also reqest an increase to the size of java.io.tmpdir
-
Hi Mark, that is difficult to say as I do no have any expirience with RedHat Linux. It would be helpful to know more details about your pipeline and the content of the ZIP documents. My guess would be, that the ZIP contains a lot of images, PDFs etc. This is because MorganaXProc-III handles the different document types defined by XProc in different ways: XML, XHTML, JSON and Text are extracted from the ZIP, parsed and held as an in memory representation. So here is no disk space involved. When it...
-
Error running <p:unarchive> on very large file (800MB)
-
MorganaXProc-IIIse released /MorganaXProc-IIIse-1.7.2/MorganaXProc-IIIse-1.7.2-sources.zip
-
-
Attribute "[p:]message" with AVT does not work on certain constructs
-
Fixed with 1.7.0
-
A Galtman posted a comment on ticket #210
Thanks a lot! I confirmed that I no longer see the error in my real use case.
-
Exception using p:xquery
-
Fixed with 1.7.1.
-
Typo in error message
-
Thanks for this! Fixed with 1.7.1
-
-
-
May be it helps to know, that the September release is scheduled for tomorrow (or Monday, if I try to include Saxon 12.9).
-
Thank you for your comments and future fix. In the meantime, I may be able to work around this by using p:set-properties to restore the base URI before calling p:xquery. (Using the c:xquery document directly doesn't work in my case due to some requirements regarding escaping.)
-
Exception using p:xquery
-
Thanks for this: The reported NullPointerException is a combination of two bugs: * p:cast-content-type does not copy the base-uri from source to result * p:xquery does not change query document for missing base-uri. The workaround for the problem is, as you said, just to leave out the p:cast-content-type in the first example. There is currently no work-around for the second problem with the xml-wrapped query. This will be fixed in the next release. Hint (as I do not known your use case exactly):...
-
Typo in error message
-
Thanks for this! This mistake is a bit awkward.
-
Typo in error message
-
Exception using p:xquery
-
p:validate-with-json-schema fails to XVRL report w/detections on invalid input
-
John Nicholas posted a comment on ticket #209
Here is the output when using json-schema-validator 1.0.79 ================================= MorganaXProc-IIIse 1.6.15 Copyright 2011-2025 by <xml-project /> Achim Berndzen ================================= Json schema validation using networknt/json-schema-validator. Copyright (c) Network New Technologies Inc. <?xml version="1.0" encoding="UTF-8"?><report xmlns="http://www.xproc.org/ns/xvrl"><metadata><timestamp>2025-09-09T12:15:12.25-04:00</timestamp><document href="file:/redact/cvr_basic_invalid_id.json"/><schema...
-
Unable to set Saxon's "expandAttributeDefaults" config option
-
I think we can close this.
-
p:validate-with-json-schema fails to XVRL report w/detections on invalid input
-
p:validate-with-json-schema fails to XVRL report w/detections on invalid input
-
Strange. If I run the pipeline, I get <report xmlns="http://www.xproc.org/ns/xvrl"> <metadata> <timestamp>2025-09-09T15:22:14.87+02:00</timestamp> <document href="file:/Users/berndzen/Desktop/XProc-Test-Cases/json-validate-209/cvr_basic_invalid_id.json"/> <schema href="file:/Users/berndzen/Desktop/XProc-Test-Cases/json-validate-209/NIST_v0_cast_vote_records.json" schematypens="JsonSchema"/> <validator name="networknt/json-schema-validator"/> </metadata> <detection severity="error" code="1028"> <location...
-
p:validate-with-json-schema fails to XVRL report w/detections on invalid input
-
Yes that makes sense. Thanks for figuring it out!
-
Hi Mark, I found out that the problem is totally unrelated to Saxon or Morgana's Saxon config. The document is not build by Saxon (that is why Saxon's expandAttributeDefaults is not respected by Saxon in MorganaXProc, but by Saxon's command line handling.) If you just have a pipeline like: <p:declare-step xmlns:p="http://www.w3.org/ns/xproc" version="3.1"> <p:output port="result" serialization="map{'indent' : true()}"/> <p:input port="source" href="oxml-sample.xml" /> <p:identity /> </p:declare-step>...
-
Also, I think the BITS DTD may be incompatible with the parser used by Saxon, i.e. expandAttributeDefaults="false" may never work with BITS XML. This is why I created a simpler DTD (OxML.dtd) and sample (oxml-sample.xml) to test the behaviour.
-
Saxon-HE? This helps because it reduces possibilities dramatically. Thanks. Achim
-
Many thanks Achim, actually I am using Saxon-HE 12.5
-
Unable to set Saxon's "expandAttributeDefaults" config option
-
Hi Mark, I will have a look at this tomorrow morning. My guess is that there is a conflict between the Saxon configuration file and MorganaXProc's configuration property "XSLTValidationMode". For my tests: Obviously you are using Saxon EE. Could you give me a hint, which version? Greetings from Germany, Achim
-
Unable to set Saxon's "expandAttributeDefaults" config option
-
Weird result of consecutive <p:rename> steps
-
Fixed with 1.6.15
-
-
-
Add support for fn4:decode-from-uri
-
Hi Nick, Thanks for this suggestion. Achim
-
Nick Nagels created ticket #207
Support for decode-from-uri
-
Weird result of consecutive <p:rename> steps
-
Weird result of consecutive <p:rename> steps
-
Hi Boris, thanks for finding this. It took some time to find the cause. The problem does not come from the consecutive rename steps, but appears right in the first rename: If an element is matched and renamed to X and the element has an attribute named "X", then the attribute is removed. (This is because currently I do not make a difference between renaming an attribute and renaming an element. And an attribute has to be removed.) The result of the first rename is: <root> <italic>italic content</italic>...
-
Boris Lehečka created ticket #206
Weird result of consecutive <p:rename> steps
-
All <detection> elements have @severity equals to 'error'
-
I think we can close this.
-
If option is called 'message' and its value contains AVT when custom step is called, message is generated twice
-
Fixed with 1.6.12
-
<p:make-absolute-uris> removes attribute if it contains whitespace
-
Fixed with 1.6.12
-
<p:rename> step throws Error in match XPath expression ...: Unexpected char 'č'
-
Fixed with 1.6.12
-
-
-
<p:rename> step throws Error in match XPath expression ...: Unexpected char 'č'
-
<p:rename> step throws Error in match XPath expression ...: Unexpected char 'č'
-
<p:make-absolute-uris> removes attribute if it contains whitespace
-
Thanks, Boris. This is a bug. The exception is silently discarded. This will be fixed in the next release.
-
Sorry, missed that: regarding option 3: I guess, when @report-format is set to xvrl, the report is generated from SVRL report generated by the Schematron implementation No, it is not. Schxslt offers a call back API, so I do not create XVRL from SVRL but directly generate XVRL. This is why some of the rulings in the XVRL draft do not apply.
-
Hi Boris, currently there is only minimal support for XVRL report in schematron as I the draft hasn't changed for years and some work needs to be done here. I try to implement only those features, I am sure they will survice. As a workaround, I used an existing svrl2xvrl.xsl stylesheet and implemented the generation of <digest> section.</digest> Yes, that would be my recommendation. It's bettet to use a stylesheet than to hard code the xvrl results in MorganaXProc as it give you more flexibility...
-
Hello Achim, regarding option 3: I guess, when @report-format is set to xvrl, the report is generated from SVRL report generated by the Schematron implementation. I know, that which parameters this conversion from native reporting format to XVRL supports is implementation-defined. I just want to point to the current XVRL draft and its Parameters for Controlling XVRL Generation chapter: The following parameters should be understood by XVRL report generators when converting underlying validation reports,...
-
<p:make-absolute-uris> removes attribute if it contains whitespace
-
All <detection> elements have @severity equals to 'error'
-
Hi Boris, I do not think that on the current level of XVRL specification there is a automated mapping between schematron's "role"-attribute and XVRL's severity attribute. The first one is a string with user defined range of value and meaning, the second has a fixed set of values and meaning. There are three options for an XProc implementer: 1. Use "severity=undefined" with might be confusing to human readers, 2. Use "severity=error" because the step specification says that every detection is an error....
-
If option is called 'message' and its value contains AVT when custom step is called, message is generated twice
-
Yes, that is definitely a bug. Thanks, Boris.
-
All <detection> elements have @severity equals to 'error'
-
If option is called 'message' and its value contains AVT when custom step is called, message is generated twice
-
p:directory-list Add support for directory/folder (within the specified folder)
-
Thanks you, Vicky.
-
Vicky Bache posted a comment on ticket #199
Here are the files following p:directory-list and the manifest created by my script, you can see that the manifest only contains directories when the max-depth is 4, but the directory-list output is actually okay. I think this can be closed and I'll rework my manifest script.
-
Hi Achim, The issue seems to be with the script I'm using to create the manifest, based on the output of p:directory-list. I think c:directory is not being picked up by that script. This is then being compensated for at a later stage- if an XML file is listed (as they all are when I use max-depth 4), then the output includes the folder structure for that XML file. I've checked the direct output of p:directory-list more closely and the c:directory elements are included whether I use 1 or 4 (which...
-
Hi Vicky, thanks for answering. With "max-depth=1" you should get all files and folders in the selected folder. At least that works for me. Greetings from Germany, Achim
-
Hi Achim, Thank you for such a quick reply. I tried one more change and it worked, apologies! <p:with-option name="max-depth" select="'4'"></p:with-option> instead of 1 (I assumed this wasn't the problem as the folders were at level 1). This ticket can be closed- Morgana is working well for my project, thank you :) Best wishes, Vicky
-
Hi Vicky, that should work. There are tests in the testsuite testing this feature. Can you post (or mail) a snippet of your pipeline? Might be important: Which OS are you on? Greetings from Germany, Achim
-
p:directory-list Add support for directory/folder (within the specified folder)
-
Typo in manual
-
Done! Thanks again for finding this, Boris.
-
Typo in manual
-
Thank you, Boris. I will try to correct the typos over the weekend.
-
Sorry, there is another one in Chapter 2.4: This implementation uses a single XSLT-Stylesheet ("transpiler.xsl") to translate the schematron to an XSLT stylesheet. "transpile.xsl"
-
Found another one in Chapter 2.3: Path to the folder withe the Skeleton files ... with the ...
-
Typo in manual
1 >