ndw / xmlcalabash1 Goto Github PK

View Code? Open in Web Editor NEW

107.0 16.0 41.0 32.5 MB

XML Calabash, an XProc processor

Home Page: http://xmlcalabash.com/

XSLT 6.88% XProc 0.55% XQuery 35.05% Java 57.17% HTML 0.35%

xml xproc pipelines

xmlcalabash1's Introduction

XML Calabash (1.x)

XML Calabash depends on Saxon and the sources vary a bit depending on the version of Saxon that you want to use.

The saxon100 branch contains the sources for the Saxon 10.5 version of XML Calabash.
The saxon99 branch contains the sources for the Saxon 9.9 version of XML Calabash.
The saxon98 branch contains the sources for the Saxon 9.8 version of XML Calabash.
The saxon97 branch contains the sources for the Saxon 9.7 version of XML Calabash.
The saxon96 branch contains the sources for the Saxon 9.6 version of XML Calabash. This is also the default branch as of 9 March 2015.
The saxon95 branch contains the sources for the Saxon 9.5 version of XML Calabash.
The saxon94 branch contains the sources for the Saxon 9.4 version of XML Calabash. I'm no longer attempting to maintain the Saxon 9.4 version.
Saxon 9.3 is no longer supported. This is the "master" branch for historical reasons.
The docs branch is moribund, see the docs repo instead.

You can download compiled versions from the releases page.

Modularity

As of version 1.1.0, XML Calabash is distributed in modules. This repository contains the core processor. The jar files from additional repositories are needed for some functionality:

Module	Functionality
deltaxml	XML comparison with Delta XML
ditaa	ASCII diagrams with ditaa
mathml-to-svg	MathML to SVG conversion with JEuclid
metadata-extractor	Image Metadata Extractor
plantuml	ASCII diagrams with PlantUML
print	Printing with XSL FO or CSS
rdf	Read/write/query RDF
sendmail	Sending email
xcc	MarkLogic XCC steps
xmlunit	XML comparison with XMLUnit

Simply place the appropriate jar files in your classpath, there's no additional configuration required. Note that you will also need commercial libraries and licenses for some steps.

These steps (and XML Calabash itself) are also available through Maven.

xmlcalabash1's People

Contributors

Stargazers

Watchers

xmlcalabash1's Issues

README says v0.9, commits say v1.x

Hmm… ☺

Perhaps your build process should auto-update the README?

Support XProcConfigurer from command line

Florent writes: http://markmail.org/message/zht4tsgkkj6gtvxv

Sorry, I forgot to say... Unless I missed something, I think
there is no way to set an XProcConfigurer from the command-line.
A bit like the Saxon 9.3 option -init which lets the user setting
a Saxon Initializer implementation from the command-line by
providing its class name.

That is, if the option is there, then Main.run use its value as
the name of a class, which must be a valid implementation of the
interface XProcConfigurer, it instantiates it (using the default
ctor) and set it on its XProcRuntime.

Add reference documentation to the distribution

Update ant to build it.
Build it as part of the dist target.
Put it in the distribution jar/zip files.

Xinclude not working…?

Desperate and in Despair

Please help me? ☺ I am at that place we’ve all been before, where the simplest thing refuses to work…and…I am about to go bats**t crazy at this point.

I am attempting to use a pipeline with a single XInclude step. And it’s failing.

I don’t mean that I get errors—I mean the XInclude just doesn’t happen. And I have spent the past 3½ hours trying to figure out why without luck. I cannot believe I’ve already wasted so much time on what is considered a fundamental building block of anything to do with anything in XML.

I don’t know if the issue is with Calabash, or Saxon, or what. But I have tried running the pipeline both from the command line and from within Oxygen, with the same results: XIncludes are not processed, no errors are emitted, and the markup or the XIncludes themselves is just copied to the output.

So, sorry if this is an inappropriate channel to ask for help. ☹ I don’t really know, because I can’t even begin to narrow the problem down. But I’ll gladly e-hug (or promise not to) any help offered, just the same!

Input Document:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html>
<html
    xmlns="http://www.w3.org/1999/xhtml"
    xmlns:xi="http://www.w3.org/2003/XInclude"
    xml:lang="en-us"
    lang="en-us">

    <head>
        <title>Untitled</title>

        <link rel="stylesheet" type="text/css" href="_css/index.css" />
    </head>

    <body>

        <xi:include parse="xml" href="_includes/header.xhtml">
            <xi:fallback> ERROR </xi:fallback>
        </xi:include>

        <div id="content">
        ... 
        </div>

        <xi:include parse="xml" href="_includes/footer.xhtml">
            <xi:fallback> ERROR </xi:fallback>
        </xi:include>

    </body>
</html>

Pipeline

<?xml version='1.0' encoding='UTF-8'?>
<p:declare-step
    name        =   "xinc"

    version     =   "1.0"
    xpath-version=  "2.0"

    xmlns:p     =   "http://www.w3.org/ns/xproc"
    xmlns:c     =   "http://www.w3.org/ns/xproc-step"
    xmlns:err   =   "http://www.w3.org/ns/xproc-error"
    xmlns:xs    =   "http://www.w3.org/2001/XMLSchema"

    xmlns:pos   =   "http://exproc.org/proposed/steps/os"
    xmlns:pxf   =   "http://exproc.org/proposed/steps/file"
    xmlns:pxfn  =   "http://exproc.org/proposed/functions"
    xmlns:pxp   =   "http://exproc.org/proposed/steps"

    xmlns:cx    =   "http://xmlcalabash.com/ns/extensions"
    xmlns:cxf   =   "http://xmlcalabash.com/ns/extensions/fileutils"
    xmlns:cxo   =   "http://xmlcalabash.com/ns/extensions/osutils"
    xmlns:cxu   =   "http://xmlcalabash.com/ns/extensions/xmlunit"

    xmlns:h     =   "http://www.w3.org/1999/xhtml/"
    xmlns:xsl   =   "http://www.w3.org/1999/XSL/Transform"
    xmlns:xi    =   "http://www.w3.org/2003/XInclude"

    xmlns:local =   "#empty">



    <p:documentation>
        <h:p>Performs simple XIncludes.</h:p>
    </p:documentation>



    <!--    
        I/O
    ======================================================================== -->
    <p:input    port="source" kind="document"   />
    <p:output   port="result"
                primary="true"  />

    <!--    
        SERIALIZATIONS 
        May bind to any output (not just "result").
    ======================================================================== -->
    <p:serialization   port    ="result" 

        doctype-system         ="about:legacy-compat"
        encoding               ="UTF-8" 
        indent                 ="true"
        media-type             ="xml" 
        method                 ="xml"
        omit-xml-declaration   ="false" 
        version                ="1.0"
    />


    <!--    
        MAIN PIPELINE CONTENT
    ======================================================================== -->
    <p:xinclude />



</p:declare-step>

Output

This is copied from my command-line attempt; Oxygen attempts have the same result (except for the Failed to obtain EE processor at the beginning, which shouldn’t matter for XInclude anyway).

Failed to obtain EE processor; using HE instead.
<html xmlns="http://www.w3.org/1999/xhtml" xmlns:xi="http://www.w3.org/2003/XInclude" xml:lang="en-us" lang="en-us">

    <head>
        <title>Untitled</title>

        <link rel="stylesheet" type="text/css" href="_css/index.css"/>
    </head>

    <body>

        <xi:include parse="xml" href="_includes/header.xhtml">
            <xi:fallback> ERROR </xi:fallback>
        </xi:include>

        <div id="content">
        ... 
    </div>

        <xi:include parse="xml" href="_includes/footer.xhtml">
            <xi:fallback> ERROR </xi:fallback>
        </xi:include>

    </body>
</html>

Version Info

$ calabash -v
XML Calabash version 1.0.2 (for Saxon 9.4.x), an XProc processor

$ saxon -versionmsg
No source file name
Saxon-HE 9.4.0.2J from Saxonica

where is the license information?

Hi ndw,

Thanks for this awesome tool.

How is it licensed?

Regards,
Darius

docs/BUGS is pointless

The content of docs/BUGS feels like a yucky bureaucratic runaround.

I recommend one of the following:

Adjusting your test suite results to write to this file
Making this a symlink to the test suite results
As a minimal, last resort: At least point the user in the right direction to find the test suite failures

Calabash does not detect Saxon PE without -a option

I'm attempting to use Saxon extension functions in an XSLT called from within a pipeline, but I get the error "Saxon extension functions are not available under Saxon-HE." However, I am using Saxon PE, so they should be available.

Using the -a command-line parameter makes it work, but since I'm using Saxon PE instead of EE, it gives a warning.

Here's the command I'm using to launch it:

java -cp y:\saxon\saxon9pe.jar;y:\saxon\;y:\calabash\calabash.jar com.xmlcalabash.drivers.Main

I'm using Saxon 9.3.0.11 and Calabash 0.9.40 on Windows 7 64-bit.

Establish p:import-able library of definitions for the XML Calabash extension steps

Give it a fixed URI and use the in-jar version?

Feature: Option to turn off p:try/p:catch exception stack trace

It should be possible to turn off any exception generated by a p:try/p:catch. For example, when the p:load fails, I don't want to see the stack trace:

com.xmlcalabash.core.XProcException: Cannot open resource riap://component/milowski.com/foo, status Not Found (404) - The server has not found anything matching the request URI
at org.atomojo.server.xproc.XProcCache$2.resolve(XProcCache.java:187)
at com.xmlcalabash.util.XProcURIResolver.resolve(Unknown Source)
at com.xmlcalabash.util.XProcURIResolver.parse(Unknown Source)
at com.xmlcalabash.core.XProcRuntime.parse(Unknown Source)
at com.xmlcalabash.library.Load.run(Unknown Source)
at com.xmlcalabash.runtime.XAtomicStep.run(Unknown Source)
...

from the pipeline:

<p:declare-step xmlns:p="http://www.w3.org/ns/xproc"
xmlns:c="http://www.w3.org/ns/xproc-step"
version="1.0"
name="test">
<p:option name="base"/>
<p:option name="remaining"/>
<p:output port="result"/>

<p:try>
<p:group>
<p:load>
<p:with-option name='href' select="concat($base,$remaining)"/>
/p:load
/p:group
<p:catch>
<p:identity>
<p:input port="source">
<p:inline>

/p:inline
/p:input
/p:identity
/p:catch
/p:try

/p:declare-step

wrong exit-status

When a pipeline terminated via xsl:message the exit-status is 0 (Calabash 1.0.3-94).
Expected result: the exit-status must be non-zero.

I wonder is the exit-status (exit-code) always 0 in Calabash?

XD0009 error with Apache Catalog Resolver

I am using simple pipeline:

<p:declare-step xmlns:p="http://www.w3.org/ns/xproc"
            name="online-help-processing"
            version="1.0">

    <p:input port="source" primary="true"/>
    <p:output port="result" primary="true"/>

    <p:xslt>
        <p:input port="stylesheet">
            <p:document href="hlp.xsl"/>
        </p:input>
    </p:xslt>

</p:declare-step>

and invoking calabash with following ant task:

        <java classname="com.xmlcalabash.drivers.Main" classpathref="transformation.class.path" failonerror="true">
            <arg line='-i source="${output.dir}/search-preprocessed.xml"'/>
            <arg line='-o result="${output.dir}/out.html"'/>

            <arg line='-U org.apache.xml.resolver.tools.CatalogResolver'/>
            <arg line='-E org.apache.xml.resolver.tools.CatalogResolver'/>

            <arg line='"online-help.xpl"'/>
            <sysproperty key="xml.catalog.files" value="${xml.catalog.files}"/>
        </java>

transformation.class.path includes saxon he, calabash and apache resolver.

In this case as only I am using -U option I am getting following errors:

25 квіт 2012 15:20:33 com.xmlcalabash.util.DefaultXProcMessageListener error
SEVERE: err:XD0009:XProc error err:XD0009
25 квіт 2012 15:20:33 com.xmlcalabash.drivers.Main error
SEVERE: It is a dynamic error if the element attribute on p:namespaces is specified and it does not identify a single element node.
25 квіт 2012 15:20:33 com.xmlcalabash.drivers.Main error
SEVERE: Underlying exception: javax.xml.transform.TransformerException: Malformed URL C:/projects/dita.project/online-help.xpl(base file:/C:/projects/dita.project/)

Am I doing something wrong? Or Calabash is not compatible with Apache Resolver

Calabash fails to fail when running a pipeline with an unbound primary input port (or so it seems)

(Calabash 1.0.3-93)

Given the following pipeline (pipeline.xpl):

<p:pipeline xmlns:p="http://www.w3.org/ns/xproc" version="1.0">
  <p:identity>
    <p:input port="source">
      <p:inline><doc/></p:inline>
    </p:input>
  </p:identity>
</p:pipeline>

If I do:

java -jar calabash.jar pipeline.xpl

then the pipeline executes with no problems and produces the result:

<doc/>

Unless there is some magic going on in Calabash, I think this is wrong because the primary input port or the pipeline is inbound. Calabash should either read the primary input from stdin, or it should fail with a dynamic error.

'docs' fails when no 'docs/build' directory

The docs target in docs/build.xml fails when docs/build does not exist, but docs/build is not in the repository and docs/build.xml does not create it. Simple solution is to add <mkdir dir="build"/> in init target.

XProc schema

I know this is not the right place for it, but since You are the author of w3c XProc recommendation i'll put it here.
XSD schema for XProc prohibits attribute name on p:catch element while the recommendation uses it in several places. Is it a bug?

Refactor code to localize serialization

There are at least three or four copies of the code that serializes. Fix that.

Jing validation: Error loading schema

I have a small XProc document that validates a document with a RelaxNG schema loaded from a p:document with a relative URI. The schema has an include element that references another schema file sitting in the same directory. When I invoke Calabash with no URI Resolve it runs fine, but it crashed with "SEVERE: com.xmlcalabash.core.XProcException: Error loading schema" when I set a URI Resolver like this:

calabash -U org.xmlresolver.Resolver test.xpl

I'll attach the samples to reproduce.

I tried to debug Calabash, and it seems Jing fails to parse the schema, complaining at some point that the "namespace URI of document element must be "http://relaxng.org/ns/structure/1.0"". I'm clueless.

Choose based on non-required option doesn't work

This doesn't seem to work in XMLCalabash (0.9.35/0.9.40), am I doing
something obvious wrong?

<p:option name="href" select="''"/>

<p:choose name="choose">
<p:when test="string-length($href) > 0">

Whatever gets passed in as $href (I can log to screen, and $href really
has a value), I always end up in the otherwise..

Reply from ndw:

A quick trace through the code shows that I clearly evaluate the
expression

boolean(string-length($href) > 0)

and get back the value of the $href variable as the result.

The mind boggles. I'll clearly have to take a deeper look. But, yeah,
I think it's an XML Calabash bug.

passing options to cx:eval throws XD0008 error

If I pass options to a cx:eval step, the evaluated pipeline fails with this error message:

step p:xslt named !1.5 at hello-world.xpl:13:hello-world.xpl:13:13:err:XD0008:
More than one document in context for parameter 'param'
It is a dynamic error if a document sequence appears where a
document to be used as the context node is expected

This is my pipeline with cx:eval step:

<p:declare-step xmlns:p="http://www.w3.org/ns/xproc" xmlns:c="http://www.w3.org/ns/xproc-step"  xmlns:cx="http://xmlcalabash.com/ns/extensions" version="1.0">

   <p:input port="source">
        <p:empty/>
    </p:input>

    <p:output port="result" sequence="true"/>

    <p:option name="import-uri" required="true"/>

    <p:import href="http://www.xyz.org/eval.lib.xpl"/>

    <p:load name="load-pipeline">
        <p:with-option name="href" select="$import-uri"/>
    </p:load>

    <cx:eval>
        <p:input port="pipeline">
            <p:pipe port="result" step="load-pipeline"/>
        </p:input>
        <p:input port="options">
            <p:inline>
                <cx:options>
                    <cx:option name="par" value="'bla'"/>
                </cx:options>
            </p:inline>
        </p:input>
    </cx:eval>

</p:declare-step>

And this is a sample pipeline which should be dynamically evaluated:

<p:declare-step xmlns:p="http://www.w3.org/ns/xproc" xmlns:c="http://www.w3.org/ns/xproc-step" xmlns:cx="http://xmlcalabash.com/ns/extensions"  version="1.0">
    <p:input port="source">
        <p:inline>
            <p xmlns="http://www.w3.org/1999/xhtml">Hello world!</p>
        </p:inline>
    </p:input>
    <p:output port="result"/>

    <p:option name="par" required="true"/>

    <p:xslt>
        <p:with-param name="param" select="$par"/>
        <p:input port="stylesheet">
            <p:inline>
                <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
                    xmlns="http://www.w3.org/1999/xhtml" version="2.0" exclude-result-prefixes="#all">

                    <xsl:param name="param"/>

                    <xsl:template match="*:p">
                        <xsl:copy>
                            <xsl:value-of select="concat( ., ' and here is my parameter ', $param)"/>
                        </xsl:copy>
                    </xsl:template>
                </xsl:stylesheet>
            </p:inline>
        </p:input>
    </p:xslt>

    <p:identity/>

</p:declare-step>

When I execute this pipeline with cx:eval I get the error message described above. When I execute the pipeline normally and pass the option "par=bla" at the command line, I get this output:

<p xmlns="http://www.w3.org/1999/xhtml" xmlns:cx="http://xmlcalabash.com/ns/extensions" 
xmlns:c="http://www.w3.org/ns/xproc-step">Hello world! and here is my parameter bla</p>

Did I do something wrong or seems this to be a bug? Unfortunately I found no examples of passing options to cx:eval. Assistance is highly appreciated.

Kind regards,

Martin

XAtomicStep doesn't give XPaths a static base URI

Attempting to call static-base-uri() in an XPath on a pipeline element (in my case, a <p:variable>) yields the empty string, instead of the base URI of the pipeline element.

It looks like this is because XAtomicStep.evaluateXPath method does not call xcomp.setBaseURI().

Feature Request: Use `<` and `>` for primary input/output

The Current Usage

Either:

$ calabash -i[port] input_file.xml -o[port] output_file.xml pipeline.xpl

Or:

$ calabash --input source=input_file.xml --output result=output_file.xml pipeline.xpl

(I have a script, /usr/local/bin/calabash, to take care of all the command-line Java weirdness that I am seemingly incapable of remembering no matter how many times I look it up. ☺)

The Ideal Usage

Since XProc requires one primary input and one primary output, would it be possible to support using standard *nix redirect characters to specify the primary I/O ports? (< and > respectively)

Example:

$ calabash < input_file.xml > output_file.xml pipeline.xpl

The idea seems very appealing to me somehow.

What about sequences?

A couple of ideas come to mind:

Allow glob syntax (*.xml) to specify multiple input files
Use quotes to specify multiple I/O files < "input1.xml input2.xml"
Allow directories for output…(?) (Just throwing out ideas: > ./dir/*.xml)
An error is printed if one of the above cannot be unambiguously determined, listing the primary I/O ports that are sequences

Benefits

Brevity of typing
More “at home” feeling for non-Java devs that use Calabash in their scripts
I’m guessing that people smarter at shell scripting than me could possibly come up with some other ingenious uses ☺

Being able to choose which configuration files are loaded

Dear Norman,
We are trying to build a system based on calabash. We noticed that when the user has a custom .calabash in their home directory it clashes with our configuration files. In order to solve this I've introduced three system properties which are checked before loading the jar config fle, the home config file and the cwd cofig file.
com.xmlcalabash.config.home
com.xmlcalabash.config.jar
com.xmlcalabash.config.cwd
A pull request is being submitted in case you're interested in adding this feature.

Thanks.

pxp:zip doesn't handle absolute manifest URIs correctly.

From http://lists.w3.org/Archives/Public/xproc-dev/2013Feb/0007.html

In pxp:zip, when an href in the manifest is an absolute HTTP
URL, FileToZip.readLastModified() sends an HTTP request. Even if
there is a document in the source port with the same base URI.

This results in the entire pipeline to fail with an exception
when there is no connection or if the domain name does not exist.
This looks like a bug to me, if a document in the source port has
the same base URI, then HTTP should never be used.

http-request doesn't handle base64 encoded input?

Is it really the case that no one's noticed this?

It appears that in the single-part case, p:http-request doesn't handle base64 encoded input at all.

Can it really be that this bug exists and no one has noticed?

synchronization of runtime load?

I am trying to load the same pipeline via the same runtime simultaneously and it looks like you need to wrap the runtime in a synchronization block.

This will fail in two different threads:

runtime.load(...same uri...)

This will succeed:

synchronized (runtime) {
runtime.load(...same uri...)
}

It seems like overkill to do it this way but the interior of the XProcRuntime instance would need to guarantee thread safety.

Calabash explicitly forbids XSLT 3.0 stylesheets

It shouldn't if Saxon EE is being used.

p:resolve-uri and xml:base

There seems to be a problem with the handling of xml:base in XML Calabash version 1.0.2 (for Saxon 9.4.x),
The pipeline below displays:

 <c:request xmlns:c="http://www.w3.org/ns/xproc-step" method="GET" detailed="true" 
      href="file:/C:/saxon/xproc.20/?doc=123"/>

In Calabash version 0.9.21 it displayed what I expected..

<c:request xmlns:c="http://www.w3.org/ns/xproc-step" method="GET" detailed="true" 
       href="http://xmlcalabash.com/?doc=123"/>

Pipeline

    <?xml version="1.0"?>
    <p:declare-step name="pipeline" version="1.0"
      xmlns:p="http://www.w3.org/ns/xproc" 
      xmlns:c="http://www.w3.org/ns/xproc-step">
      <p:output port="result"/>
        <p:variable name="item" select="123"/>
         <p:string-replace match="/c:request/@href">
          <p:input port="source">
            <p:inline>
              <c:request method="GET" detailed="true" href="@@HERE@@" />
            </p:inline>
          </p:input>
          <p:with-option name="replace"
            select="concat('&quot;'
                           ,p:resolve-uri(/urls/req[@type='doc']/@url)
                           ,$item
                           ,'&quot;')">
            <p:inline>
              <urls xml:base="http://xmlcalabash.com/">
                <req type="doc" url="?doc=" />
                <req type="compID" url="?compID=" />
              </urls>
            </p:inline>
          </p:with-option>
        </p:string-replace>
    </p:declare-step>

Preemptive Authentication for XCC

To avoid double requests with the ML steps, setAuthenticationPreemptive(true); needs to be called on ContentSource.

Enhancement: Metadata about Static Resources

For systems that want to detect when an ancillary file has changed and so pipelines need to be re-loaded, it would be nice to get a list of statically configured pipeline resources (e.g. things pointed to by p:document/@href).

Improve handling of extension attributes from running steps

Florent wrote: http://markmail.org/message/ivfpsyvyb3hxinle

* Made sure extension attributes are processed on all
  elements; added hook for an XStep to get access to the
  underlying Step for access to extension attributes on
  descendants.

Thanks. That solves the problem for XSteps. But most of the
steps are not XSteps, they are XProcSteps. And in Calabash those
are even all extending DefaultStep. So they have an
XAtomicStep (which is an XStep), but they are not an XStep
themselves.

I guess a simple and convenient solution is to add a method
like the following to DefaultStep, in order for extension code
manipulating steps to access the underlying XStep and thus the
extension attribtues:

public XAtomicStep getUnderlyingStep() {
    return step;
}

or preferably a more dedicated one like:

public String getExtensionAttribute(QName name) {
    return step == null
        ? null
        : step.getExtensionAttribute(name);
}

Feature suggestion: add support for gzip

EXProc already adds support for ZIP files (http://exproc.org/proposed/steps/other.html#zip).

I have to deal with XML files that are publicly available on the web as gzip archives. It would be great if it were possible to work with the archives as a step in the pipeline - via a pair of steps pxp:gzip and pxp:ungzip similar to the pxp:zip and pxp:unzip steps.

pxf:delete doesn't delete recursively

It seems that there is an issue with the pxf:delete step from the exproc proposed extensions. The step worked for me only for directories without subfolders. Here is a my error message:

25.01.2012 18:08:34 com.xmlcalabash.util.DefaultXProcMessageListener error
SCHWERWIEGEND: base/testdel.xpl:16:69:Delete failed for: test1
25.01.2012 18:08:34 com.xmlcalabash.drivers.Main error
SCHWERWIEGEND: com.xmlcalabash.core.XProcException: Delete failed for: test1

My pipeline is as follows:

<?xml version="1.0" encoding="UTF-8"?>
<p:declare-step 
    xmlns:p="http://www.w3.org/ns/xproc"
    xmlns:pxf="http://exproc.org/proposed/steps/file"
    xmlns:c="http://www.w3.org/ns/xproc-step" version="1.0">

    <p:input port="source">
        <p:empty/>
    </p:input>
    <p:output port="result"/>

    <p:import href="install-lib.xpl"/>

    <pxf:mkdir href="test1/test2"/>

    <pxf:delete href="test1" recursive="true" fail-on-error="true"/>

    <p:identity>
        <p:input port="source">
            <p:inline>
                <c:result>something</c:result>
            </p:inline>
        </p:input>
    </p:identity>
</p:declare-step>

Could anybody reproduce this issue?

unzip with p:store (cx:decode)

I want to download a zip and extract all contents ... I thought this would be made easier/possible using cx:decode="true" on store step. This is especially a problem in terms of handling zips containing multiple file types (containing images, html, xml, etc)... its not entirely clear.

Consider the following example pipeline, which downloads manifest from a test.zip and attempts to store each item in its native form ... this results in a bunch of base64 encoded files.

<?xml version="1.0" encoding="UTF-8"?>
<p:declare-step 
    xmlns:c="http://www.w3.org/ns/xproc-step"
    xmlns:p="http://www.w3.org/ns/xproc"
    xmlns:cx="http://xmlcalabash.com/ns/extensions"
    xmlns:depx="https://github.com/xquery/depx"
    name="generate-package"
    version="1.0"
    exclude-inline-prefixes="cx c p">

  <p:import href="extension-library.xml"/>

    <cx:unzip>
       <p:with-option name="href" select="'http://localhost/test.zip'"/>
    </cx:unzip>

    <p:for-each>
        <p:iteration-source select="//c:file"/>
        <p:variable name="file" select="c:file/@name"/>

        <cx:unzip>
          <p:with-option name="content-type" select="'*'"/>
          <p:with-option name="href" select="'http://localhost/test.zip'"/>
          <p:with-option name="file" select="$file"/>
        </cx:unzip>

        <p:store cx:decode="true">
          <p:with-option name="href" select="concat('/Users/jfuller/Source/Webcomposite/xproc-tests/',$file)"/>
        </p:store>

    </p:for-each>

  <!-- run pipeline manually in emacs with m-x compile //-->
  <p:documentation>
    (:
    -- Local Variables:
    -- compile-command: "/usr/local/bin/calabash test-zip.xpl"
    -- End:
    :)
  </p:documentation>


</p:declare-step>

NullPointerException in com.xmlcalabash.util.XProcURIResolver

I have an XProc with code like this:
.................
<p:xsl-formatter content-type="application/pdf">
<p:with-option name="href" select="$pdf-file"></p:with-option>
<p:with-param name="UserConfig" select="$fop-config"/>
</p:xsl-formatter>
...................

which tries to generate PDF using Apache FOP.

The FOP configuration file looks like this:

When transforming, the output fails with a message like:

Failed to process FO document with FOP null

which is actually generated by:

Caused by: java.lang.NullPointerException
at java.net.URI$Parser.parse(Unknown Source)
at java.net.URI.(Unknown Source)
at com.xmlcalabash.util.XProcURIResolver.resolve(Unknown Source)
at org.apache.fop.apps.FOURIResolver.resolve(FOURIResolver.java:179)
at org.apache.fop.apps.FopFactory.resolveURI(FopFactory.java:753)
at org.apache.fop.apps.FOUserAgent.resolveURI(FOUserAgent.java:425)
at org.apache.fop.render.DefaultFontResolver.resolve(DefaultFontResolver.java:44)
at org.apache.fop.fonts.FontLoader.openFontUri(FontLoader.java:154)
at org.apache.fop.fonts.truetype.TTFFontLoader.read(TTFFontLoader.java:94)
at org.apache.fop.fonts.truetype.TTFFontLoader.read(TTFFontLoader.java:84)
at org.apache.fop.fonts.FontLoader.getFont(FontLoader.java:190)
at org.apache.fop.fonts.FontLoader.loadFont(FontLoader.java:139)
at org.apache.fop.fonts.LazyFont.load(LazyFont.java:134)
at org.apache.fop.fonts.LazyFont.getAscender(LazyFont.java:241)
at org.apache.fop.fonts.Font.getAscender(Font.java:106)
at org.apache.fop.layoutmgr.BlockLayoutManager.initialize(BlockLayoutManager.java:87)
at org.apache.fop.layoutmgr.AbstractLayoutManager.getChildLM(AbstractLayoutManager.java

So the method:

public Source resolve(String href, String base) throws TransformerException {

receives a NULL base from Apache FOP and tries to make an URI out of it:

URIResolver(file:/C:/Windows/FONTS/arial.ttf,null)

So you should take into account on the URIResolver the possibility of a NULL base.

The workaround is simple, a "./" can be specified in the configuration file in order for Apache FOP to also specify the base in the URI resolver and avoid the NPE.

One more improvement which would help debug such cases would be that in the method:

com.xmlcalabash.library.XSLFormatter.run()

when an exception is caught, it should not be ignored but instead be provided as the cause of the thrown XProcException.

'docs' fails with XPointer/XInclude error

Getting this error when running distrib target:

docs:
     [java] 16-May-2012 17:21:27 com.xmlcalabash.util.DefaultXProcMessageListener error
     [java] SEVERE: err:XC0001:XPointer is not allowed on XInclude when parse='text'
     [java] 16-May-2012 17:21:27 com.xmlcalabash.drivers.Main error
     [java] SEVERE: Unknown error
     [java] com.xmlcalabash.core.XProcException: XPointer is not allowed on XInclude when parse='text'
     [java]     at com.xmlcalabash.core.XProcException.stepError(XProcException.java:184)
     [java]     at com.xmlcalabash.library.XInclude.processStartElement(XInclude.java:162)
     [java]     at com.xmlcalabash.util.ProcessMatch.traverse(ProcessMatch.java:201)
     [java]     at com.xmlcalabash.util.ProcessMatch.traverse(ProcessMatch.java:235)
     [java]     at com.xmlcalabash.util.ProcessMatch.traverse(ProcessMatch.java:235)
     [java]     at com.xmlcalabash.util.ProcessMatch.traverse(ProcessMatch.java:235)
     [java]     at com.xmlcalabash.util.ProcessMatch.traverse(ProcessMatch.java:235)
     [java]     at com.xmlcalabash.util.ProcessMatch.match(ProcessMatch.java:97)
     [java]     at com.xmlcalabash.library.XInclude.expandXIncludes(XInclude.java:129)
     [java]     at com.xmlcalabash.library.XInclude.processStartElement(XInclude.java:220)
     [java]     at com.xmlcalabash.util.ProcessMatch.traverse(ProcessMatch.java:201)
     [java]     at com.xmlcalabash.util.ProcessMatch.traverse(ProcessMatch.java:235)
     [java]     at com.xmlcalabash.util.ProcessMatch.traverse(ProcessMatch.java:190)
     [java]     at com.xmlcalabash.util.ProcessMatch.match(ProcessMatch.java:97)
     [java]     at com.xmlcalabash.library.XInclude.expandXIncludes(XInclude.java:129)
     [java]     at com.xmlcalabash.library.XInclude.run(XInclude.java:120)
     [java]     at com.xmlcalabash.runtime.XAtomicStep.run(XAtomicStep.java:366)
     [java]     at com.xmlcalabash.runtime.XPipeline.doRun(XPipeline.java:236)
     [java]     at com.xmlcalabash.runtime.XPipeline.run(XPipeline.java:136)
     [java]     at com.xmlcalabash.drivers.Main.run(Main.java:320)
     [java]     at com.xmlcalabash.drivers.Main.main(Main.java:76)

Calabash runs out of memory in combination with streaming in saxon

As a part of my pipeline, I am calling an XSLT stylesheet split.xsl which uses streaming.
split.xsl consumes one larger XML file and splits it into a bunch of smaller ones through xsl:result-document.
split.xsl is in fact called repeatedly for a bunch of those larger XML files. Something like

foreach large file f
   split file f into smaller files
   save each smaller file

This process quickly eats up all free physical memory.

This is how the saving part looks like:

<p:xslt name="xslt-split" template-name="main" initial-mode="s">
    <p:input port="source">
        <p:empty/>
    </p:input>
    <p:input port="stylesheet">
        <p:document href="split.xsl"/>
    </p:input>
    <p:input port="parameters">
        <p:pipe step="prepare-params-for-xslt-split" port="result"/>
    </p:input>
</p:xslt>

<p:store name="store-xslt-result">
    <p:with-option name="href" select="concat($split-folder,'/result-', $bare-filename)"/>
</p:store>

<p:for-each name="store-xslt-secondary-results">
    <p:iteration-source>
        <p:pipe step="xslt-split" port="secondary"/>
    </p:iteration-source>
    <p:store>
        <p:with-option name="href" select="p:base-uri()"/>
    </p:store>
</p:for-each>

I am not sure what causes the problem (but I think it is not Saxon, because the streaming really works and the big document is never loaded into the memory whole in one time).

Is it because that Calabash still holds the documents coming out from the secondary port in the memory? Do you have any suggestions on how to make this process work? I can provide the complete example if need be.

"test" option problem in p:split-sequence

Hi
I think there is design bug in "computeValue" method of "XAtomicStep". On the 551 line You check if there is more documents in the pipe and if so, exception is thrown "More than one document in context for parameter...". This prevents SplitSequence class to run.

There is also another issue here. The xpath expression is evaluated first in XAtomicStep.computeValue method and so the result of this evaluation is passed to the run method of SplitSequence class. In order to properly evaluate test expression in SplitSequence you have to wrap it in additional quotes.
Should it be like that?

XProc recomendation in 2.6 says:

XPath expressions are also passed to some steps. These expressions are evaluated by the implementations of the individual steps.

and further:

The XPath expression “@ROLE='chapter'” is passed literally to the test option on the p:split-sequence step. That's because the nature of the p:split-sequence is that it evaluates the expression. Only some options on some steps expect XPath expressions.

where is the license information?

Hi ndw,

Thanks for this awesome tool.

How is it licensed?

Regards,
Darius

Custom Configuration for XProcConfiguration

I'd like to instantiate the XProcConfiguation with my own XML document (or a location of one) so I can tweak the default step implementations. Currently, the constructor will call "loadConfiguration()". Later, I can call "parse()" with my own XML but the configuration has already loaded itself at that point.

My use case: I want to replace the implementation of p:http-request.

ThreadLocal use produces memory leaks in pooled environments

Hi,

In several classes the XProcRuntime object is stored in ThreadLocal variables. This leads to important memory leaks when calabash is used within a ThreadPool (as the objects are never collected by the GC). I reckon that the cleanest way is solve this issue is to wrap these objects around a WeakReference.

I've got the modified classes (src/com/xmlcalabash/functions/*) under a local branch that I could push if you wish.

Even doing that the memory leak persists as Saxon stores the XProcRuntime object in another ThreadLocal as shown in this trace:
com.xmlcalabash.core.XProcRuntime
runtime of com.xmlcalabash.util.XProcURIResolver
uriResolver of net.sf.saxon.Configuration
notationSet of net.sf.saxon.lib.ConversionRules
conversionRules of net.sf.saxon.type.StringConverter$StringToAnyURI
value of java.util.LinkedHashMap$Entry
[62] of java.util.HashMap$Entry[64]
table of net.sf.saxon.expr.sort.LRUCache$1
map of net.sf.saxon.expr.sort.LRUCache
value of java.lang.ThreadLocal$ThreadLocalMap$Entry
[105] of java.lang.ThreadLocal$ThreadLocalMap$Entry[128]
table of java.lang.ThreadLocal$ThreadLocalMap
threadLocals of java.lang.Thread [Stack Local]

Thanks

Feature suggestion: step which prints its input to the console

I find cx:message step very useful for debugging XPath expressions.
I would be glad for a similarly straightforward way to see the documents passed between the steps (especially the http requests and responses). So far, I am using p:store to save them to temporary files, but it is a bit cumbersome. So, consider adding a step

cx:print-to-console

which behaves like p:identity, but also prints the documents from the input port to the console.

subresources for jar loaded pipelines do not load properly

If you load a pipeline with a jar URI:

     pipeline = runtime.load(MyStuff.class.getResource("insert.xpl").toString());

any document pointed to by a <p:document href="..."/> won't load. My expectation is the base URI is the jar URI and so those reference should resolve against the jar file as well.

By default, this does not work. Somehow the base URI isn't resolving the relative reference and the system expects to find it relative to the current directory.

docs/Changelog is way outdated

The Changelog’s las entry is 0.7.x! =^o

Null pointer exception from bad p:with-option

If you mistakenly put in a bad p:with-option without a name attribute you get a null pointer exception:

java.lang.NullPointerException
at com.xmlcalabash.model.Parser.readOption(Unknown Source)
at com.xmlcalabash.model.Parser.readSignature(Unknown Source)
at com.xmlcalabash.model.Parser.readStep(Unknown Source)
at com.xmlcalabash.model.Parser.parseDeclareStepBody(Unknown Source)
at com.xmlcalabash.model.Parser.usePipeline(Unknown Source)
at com.xmlcalabash.model.Parser.loadPipeline(Unknown Source)
at com.xmlcalabash.core.XProcRuntime._load(Unknown Source)
at com.xmlcalabash.core.XProcRuntime.load(Unknown Source)

<cx:eval> doesn't work (NPE, other weird errors)

With Calabash 1.0.3 (for Saxon-HE 9.4.0.2), I get a NullPointerException when trying to use <cx:eval>, and some really strange errors if I fix the NPE.

In my test case, I have two files, named pipe1.xpl and pipe2.xpl, containing:

pipe1.xpl:

<p:library xmlns:p="http://www.w3.org/ns/xproc" version="1.0" xmlns:test="http://example.com/">
        <p:pipeline type="test:pipe1" name="pipe-1">
                <p:identity/>
        </p:pipeline>
</p:library>

pipe2.xpl:

<p:pipeline xmlns:p="http://www.w3.org/ns/xproc" version="1.0" xmlns:test="http://example.com/" xmlns:cx="http://xmlcalabash.com/ns/extensions">
        <p:import href="http://xmlcalabash.com/extension/steps/library-1.0.xpl"/>

        <cx:eval step="test:pipe1">
                <p:input port="pipeline">
                        <p:document href="pipe1.xpl"/>
                </p:input>
                <p:input port="options">
                        <p:empty/>
                </p:input>
        </cx:eval>
</p:pipeline>

This yields:

Sep 30, 2012 1:04:14 AM com.xmlcalabash.drivers.Main error
SEVERE: Pipeline failed: java.lang.NullPointerException

The problem is that XProcRuntime.xprocData doesn't get copied by XProcRuntime's copy constructor. If I fix it just by adding xprocData = runtime.xprocData; to said constructor, though, I then get this stuff instead:

Sep 30, 2012 1:06:07 AM com.xmlcalabash.util.DefaultXProcMessageListener error
SEVERE: pipe1.xpl:2:46:Declared step has no subpipeline, but is not known.
Sep 30, 2012 1:06:07 AM com.xmlcalabash.util.DefaultXProcMessageListener error
SEVERE: No in-scope binding for source on XML-CALABASH-GENERATED-WRAPPER-PIPELINE
Sep 30, 2012 1:06:07 AM com.xmlcalabash.util.DefaultXProcMessageListener error
SEVERE: No in-scope binding for source on XML-CALABASH-GENERATED-WRAPPER-PIPELINE
Sep 30, 2012 1:06:07 AM com.xmlcalabash.drivers.Main error
SEVERE: com.xmlcalabash.core.XProcException: No in-scope binding for source on XML-CALABASH-GENERATED-WRAPPER-PIPELINE

Yikes. That looks like some kind of bug, hence this report.

I ran into this problem while trying to drive Calabash programmatically. I had been trying to get and run an XPipeline from its enclosing XLibrary, and got the error about "declared step has no subpipeline". At first, I thought I must have been doing something wrong, but then I found that <cx:eval> does the same thing and has the same problem…

XMLResolver not using stylesheet location to resolve relative urls

Not sure if this belongs to current project. However when I am using your XMLResolver with Calabash during resolving of imports current working directory is used as base path instead of xsl location.
For example:
current working dir is: 'C:/projects/dita.project'
pipeline calling xsl using relative path: 'hlp/hlp.xsl'
hlp.xsl contain import with path '../common/common-functions.xsl'

during execution of such pipeline I am getting following exception:

SEVERE: 12:err:XTSE0165:I/O error reported by XML parser processing 
file:/C:/projects/common/common-functions.xsl: C:\projects\common\common-functions.xsl 
(The system cannot find the path specified)

It is starting relative path from current working dir instead of xsl location

p:exec misinterprets argument with variables

The issue relates to the assignment of arguments to p:exec steps. I want to implement jing with p:exec, because the p:validate-with-relax-ng step is useless to me without report port and readable output. Here is my pipeline:


<?xml version="1.0" encoding="UTF-8"?>
<p:declare-step 
    xmlns:p="http://www.w3.org/ns/xproc"
    xmlns:c="http://www.w3.org/ns/xproc-step"
    version="1.0">
    <p:option name="input"/>
    <p:option name="schema"/>
    <p:input port="source"/>
    <p:output port="result"/>    
    <p:exec command="jing"
        source-is-xml="true"
        result-is-xml="false"
        wrap-result-lines="true"
        arg-separator=","> 
        <p:with-option name="args" select="$schema,' ',$input"/>
    </p:exec>
</p:declare-step>

I execute the step on the command line as follows:


calabash test-validate.xpl schema=xhtml-basic.rng input=test.html

This leads to this output:


Loading catalog: file:/usr/share/xml/catalog.xml
Resolved URI: test-validate.xpl
    file:/Users/Martin/workspace/epubcheck-xproc/xproc/test-validate.xpl
<c:result xmlns:c="http://www.w3.org/ns/xproc-step"><c:line>fatal: file not found: xhtml-basic.rng test.html (No such file or directory)</c:line>
</c:result>

Jing complains that the files cannot be found. Ironically, I do not get this error message when I execute Jing directly over the command line:

jing xhtml-basic.rng test.html
/Users/Martin/workspace/test.html:10:53: error: attribute "style" not allowed here; expected attribute "id", "title" or "xml:lang"
...

When I pass the variables as args without whitespace, then calabash pass the parameters to Jing without any whitespace which leads to the same file-not-found error. Also invoking jing with

<p:exec command="java"
        source-is-xml="true"
        result-is-xml="false"
        wrap-result-lines="true"
        arg-separator=",">
        <p:with-option name="args" select="concat('-jar ../calabash/lib/jing.jar', ' ', $schema, ' ', $input)"/>
    </p:exec>

leads to an similar error message by the java virtual machine:

Unrecognized option: -jar ../calabash/lib/jing.jar ../rng/xhtml-basic.rng test.html
Could not create the Java virtual machine.

I used Calabash 0.9.34

EntityResolver never used

I tried to hook in an entity resolver to use the internal client of the Restlet libraries I'm using but it looks like my resolver is never called:

INFO: Running load !1.4
com.xmlcalabash.core.XProcException: XProc error err:XD0011
at com.xmlcalabash.core.XProcException.dynamicError(Unknown Source)
at com.xmlcalabash.util.XProcURIResolver.parse(Unknown Source)
at com.xmlcalabash.core.XProcRuntime.parse(Unknown Source)
at com.xmlcalabash.library.Load.run(Unknown Source)
at com.xmlcalabash.runtime.XAtomicStep.run(Unknown Source)
at com.xmlcalabash.runtime.XPipeline.doRun(Unknown Source)
at com.xmlcalabash.runtime.XPipeline.run(Unknown Source)
at org.atomojo.server.xproc.XProcRestlet.handle(XProcRestlet.java:577)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at org.restlet.routing.Filter.handle(Filter.java:203)
at org.restlet.routing.Router.doHandle(Router.java:428)
at org.restlet.routing.Router.handle(Router.java:645)
at org.atomojo.server.ConfiguredHost$1.handle(ConfiguredHost.java:61)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at org.restlet.routing.Filter.handle(Filter.java:203)
at org.restlet.routing.Router.doHandle(Router.java:428)
at org.restlet.routing.Router.handle(Router.java:645)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at org.restlet.engine.application.StatusFilter.doHandle(StatusFilter.java:151)
at org.restlet.routing.Filter.handle(Filter.java:203)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at org.restlet.routing.Filter.handle(Filter.java:203)
at org.restlet.engine.CompositeHelper.handle(CompositeHelper.java:208)
at org.restlet.Component.handle(Component.java:389)
at org.restlet.Server.handle(Server.java:513)
at org.restlet.engine.ServerHelper.handle(ServerHelper.java:69)
at org.restlet.engine.adapter.HttpServerHelper.handle(HttpServerHelper.java:149)
at org.restlet.ext.jetty.JettyServerHelper$WrappedServer.handle(JettyServerHelper.java:167)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:589)
at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:1048)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:601)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:214)
at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:535)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:40)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:529)
at java.lang.Thread.run(Thread.java:680)
Caused by: net.sf.saxon.s9api.SaxonApiException: I/O error reported by XML parser processing riap://component/milowski.com/: unknown protocol: riap
at net.sf.saxon.s9api.DocumentBuilder.build(DocumentBuilder.java:402)
... 36 more
Caused by: net.sf.saxon.trans.XPathException: I/O error reported by XML parser processing riap://component/milowski.com/: unknown protocol: riap
at net.sf.saxon.event.Sender.sendSAXSource(Sender.java:427)
at net.sf.saxon.event.Sender.send(Sender.java:154)
at net.sf.saxon.Configuration.buildDocument(Configuration.java:3321)
at net.sf.saxon.s9api.DocumentBuilder.build(DocumentBuilder.java:399)
... 36 more
Caused by: java.net.MalformedURLException: unknown protocol: riap
at java.net.URL.(URL.java:574)
at java.net.URL.(URL.java:464)
at java.net.URL.(URL.java:413)
at org.apache.xerces.impl.XMLEntityManager.setupCurrentEntity(Unknown Source)
at org.apache.xerces.impl.XMLVersionDetector.determineDocVersion(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at net.sf.saxon.event.Sender.sendSAXSource(Sender.java:400)
... 39 more
Oct 26, 2011 12:13:34 PM com.xmlcalabash.util.DefaultXProcMessageListener error
SEVERE: err:XC0011:Could not load riap://component/milowski.com/ (file:/Users/alex/workspace/milowski/web/milowski.com/docs/test.xpl) dtd-validate=false
Oct 26, 2011 12:13:34 PM org.restlet.engine.application.StatusFilter doHandle
WARNING: Exception or error caught in status service
com.xmlcalabash.core.XProcException: Could not load riap://component/milowski.com/ (file:/Users/alex/workspace/milowski/web/milowski.com/docs/test.xpl) dtd-validate=false
at com.xmlcalabash.core.XProcException.stepError(Unknown Source)
at com.xmlcalabash.library.Load.run(Unknown Source)
at com.xmlcalabash.runtime.XAtomicStep.run(Unknown Source)
at com.xmlcalabash.runtime.XPipeline.doRun(Unknown Source)
at com.xmlcalabash.runtime.XPipeline.run(Unknown Source)
at org.atomojo.server.xproc.XProcRestlet.handle(XProcRestlet.java:577)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at org.restlet.routing.Filter.handle(Filter.java:203)
at org.restlet.routing.Router.doHandle(Router.java:428)
at org.restlet.routing.Router.handle(Router.java:645)
at org.atomojo.server.ConfiguredHost$1.handle(ConfiguredHost.java:61)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at org.restlet.routing.Filter.handle(Filter.java:203)
at org.restlet.routing.Router.doHandle(Router.java:428)
at org.restlet.routing.Router.handle(Router.java:645)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at org.restlet.engine.application.StatusFilter.doHandle(StatusFilter.java:151)
at org.restlet.routing.Filter.handle(Filter.java:203)
at org.restlet.routing.Filter.doHandle(Filter.java:156)
at org.restlet.routing.Filter.handle(Filter.java:203)
at org.restlet.engine.CompositeHelper.handle(CompositeHelper.java:208)
at org.restlet.Component.handle(Component.java:389)
at org.restlet.Server.handle(Server.java:513)
at org.restlet.engine.ServerHelper.handle(ServerHelper.java:69)
at org.restlet.engine.adapter.HttpServerHelper.handle(HttpServerHelper.java:149)
at org.restlet.ext.jetty.JettyServerHelper$WrappedServer.handle(JettyServerHelper.java:167)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:589)
at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:1048)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:601)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:214)
at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:411)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:535)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:40)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:529)
at java.lang.Thread.run(Thread.java:680)

cx:namespace-delete doesn't

Namespace delete doesn't delete the default namespace or the namespace associated with an element if that element is in that namespace.

This is for Saxon 9.3 I haven't tested Saxon 9.4.

cz:unzip throws 'no class in configuration'

using xmlcalabash-0.9.43.94

getting the following when a pipeline tries to utilize the cx:unzip step

Jan 6, 2012 9:15:56 PM com.xmlcalabash.drivers.Main error
SEVERE: Pipeline failed: java.lang.UnsupportedOperationException:
Misconfigured. No 'class' in configuration for cx:unzip
java.lang.UnsupportedOperationException: Misconfigured. No 'class' in configuration for cx:unzip
at com.xmlcalabash.core.XProcConfiguration.newStep(XProcConfiguration.java:412)
at com.xmlcalabash.runtime.XAtomicStep.run(XAtomicStep.java:277)
at com.xmlcalabash.runtime.XCompoundStep.run(XCompoundStep.java:256)
at com.xmlcalabash.runtime.XChoose.run(XChoose.java:132)
at com.xmlcalabash.runtime.XPipeline.doRun(XPipeline.java:236)
at com.xmlcalabash.runtime.XPipeline.run(XPipeline.java:136)
at com.xmlcalabash.drivers.Main.run(Main.java:320)
at com.xmlcalabash.drivers.Main.main(Main.java:81)

Feature: Option to prevent expansion of defaulted attributes

It should be possible to turn off the automatic expansion of defaulted attributes.
Whenever you process XML files with lots of defaulted attributes, the filesize grows enormous because of the defaulted attributes which get expanded.
It would be nice to be able to turn that behaviour (which is in fact default behaviour) off.

ndw / xmlcalabash1 Goto Github PK

xmlcalabash1's Introduction

XML Calabash (1.x)

Modularity

xmlcalabash1's People

Contributors

Stargazers

Watchers

Forkers

xmlcalabash1's Issues

Desperate and in Despair

Input Document:

Pipeline

Output

Version Info

The Current Usage

The Ideal Usage

What about sequences?

Benefits

Recommend Projects

Recommend Topics

Recommend Org