Recent changes to feature-requests

#8 Core functions

Keith D Gregory — Fri, 23 Jun 2017 11:05:32 -0000

status: open --> wont-fix

#8 Core functions

Keith D Gregory — Fri, 23 Jun 2017 11:04:19 -0000

This is actually a limitation of the JDK, and perhaps of the XPath 1.0 expression syntax (although I've been looking at the BNF to determine just how a LocationPath is a special case of an Expr, and am not finding anything clear -- I would have expected a LocationPath to be one of the PrimaryExpr forms, but it isn't).

Regardless, it isn't an issue with binding. Here are some examples of using name():

    Document dom = ParseUtil.parse("<root>"
                                 + "  <child>"
                                 + "    <grandchild>text</grandchild>"
                                 + "  </child>"
                                 + "</root>");

    XPathWrapper wrapper1 = new XPathWrapper("name(/root/child)");
    System.out.println(wrapper1.evaluateAsString(dom));

    // note that this second example selects only text, including whitespace
    XPathWrapper wrapper2 = new XPathWrapper("/root/*[name()='child']");
    System.out.println(wrapper2.evaluateAsString(dom));

Core functions

Christian Mueller — Tue, 20 Jun 2017 19:02:33 -0000

Hi,
I am testing the XPathWraper and have a problem by using core functions.

    private XPathWrapperFactory wrapperFactory = new XPathWrapperFactory()
            .bindNamespace("bpmn", "http://www.omg.org/spec/BPMN/20100524/MODEL")
            .bindNamespace("form", "http://www.bpsim.org/schemas/1.0");

     Document dom = ParseUtil.parse(new File("Model/Test3.bpmn"));

      XPathWrapper xpw = wrapperFactory.newXPath("../../../../../../../name()");
      result = xpw.evaluateAsString(dom);

and I get:
Exception in thread "main" net.sf.practicalxml.XmlException: unable to compile: ../../../../../../../name()

What is wrong? must I bind the core functions?

Christian

Core functions

Christian Mueller — Tue, 20 Jun 2017 19:02:33 -0000

Ticket 8 has been modified: Core functions
Edited By: Keith D Gregory (kdgregory)
Status updated: u'open' => u'wont-fix'

Bean conversion: support XSD binary encoding types for byte[]

Keith D Gregory — Tue, 08 Oct 2013 20:08:36 -0000

Current transformation of a byte[] is as a series of separate elements, each containing one byte. This is extremely inefficient.

XSD specifies two encodings for arbitrary binary data, and both should be supported via options. See http://www.w3.org/TR/xmlschema-2/#base64Binary and http://www.w3.org/TR/xmlschema-2/#hexBinary for details.

Open issue: should one of these be the default encoding for byte[]? My thought is yes: I think it's unlikely that existing code would be broken by making the current nested-element format be an option.

I lean toward the hex-encoded version being default, as it provides the most benefit as a text format (ie, there are likely to be applications that can use the encoded value directly, without the need to translate back to byte[]; base-64 requires decoding to be useful).

Support indented output on Xalan

Keith D Gregory — Fri, 30 Aug 2013 12:54:16 -0000

Xalan does not accept the indentation config in OutputUtil, will throw.

Solution will be to look at transformer implementation class, choose alternative mechanism or ignore.

#5 Handle dates better

Keith D Gregory — Fri, 30 Aug 2013 12:52:55 -0000

java.util.Calendar support improved in 1.1.14 or 1.1.15 (wasn't a separate commit)

subclasses of java.util.Date supported in 1.1.16

XmlGregorianCalendar still outstanding, because it's not really a Date.

Should also support JODA.

#4 Add option to defer exceptions

Keith D Gregory — Fri, 30 Aug 2013 12:50:27 -0000

status: open --> closed

Handle dates better

Keith D Gregory — Tue, 18 Jun 2013 01:50:32 -0000

Current bean->xml formatting rules for a java.util.Date will either write using toString() or in XSD format; for a java.util.Calendar, a subset of fields get written (including dates in whatever format is active), and XmlGregorianCalendar gets written as all fields. Consistency would be nice.

Add option to defer exceptions

Keith D Gregory — Tue, 18 Jun 2013 01:46:40 -0000

Rather than throw an exception as soon as the converter is unable to process a node, provide an option to record the exception and skip the node.