Nicholas Bastin wrote:
We're starting to have real problems with the fact that XNumber in our
extension function argument lists only resolves to a double, which
leads me to two questions:
1) Is there any sort of standard validator mechanism that we can use
to validate that a particular argument is of the right type (not just
"number") before we get it out on the other side?
What types are you interested in, and what is "the other side?"
2) Are there any plans to increase the resolution of XObject such that
instead of XNumber, we get some more refined types (specifically a
problem for us when the integer type we want is larger than a double
and doesn't cast well).
Unlikely, because the XPath data model only has one numeric data type, and
that's an IEEE754 floating point type.
Also, maybe there's a mechanism for writing custom argument parsers?
The documentation isn't that thorough on the subject of extension
functions, so I could be missing something entirely.
I'm not sure what you mean by a "custom argument parser." Can you be more
specific? Do you mean parsing numeric literals in XPath expressions? If
so, then you would need to modify Xalan-C yourself to extend it.
On the other hand, the XObject hierarchy is flexible enough that you could
extend it by adding your own types, as long as you satisfy one of the
following:
1. Don't pass them to any standard XPath or XSLT functions
2. Ensure that they can be coerced to one of the standard XPath types if
you want to pass them to standard XPath or XSLT functions.
The easiest way for you to implement this is by having a factory function
that accepts a string literal that indicates what sort of XObject
derivative you want to create, parses that string, then creates the right
instance of one of your derived types. You can then pass that to your
extensions functions, or to one of the standard functions, as long as you
observe my previous point 2.
Dave
