Validators/Formatters for XNumber?

[Nicholas Bastin <ni...@gmail.com>]

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?

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).

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.

--
Nick

Re: Validators/Formatters for XNumber?

[Nicholas Bastin <ni...@gmail.com>]

On 8/17/07, David Bertoni <db...@apache.org> wrote:
> 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?"

Basically, the code that reads over the values in XObjectArgVectorType&.

> > 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.

Basically, so we could feed our own subclasses of XObject into the
XObjectArgVectorType object between when the extension is called in
the XSLT, and the extension function is actually called.  Some sort of
a Validator shim, so to speak.

> 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.

Yeah, this seems like the way to go in the current architecture.  Just
grab the XalanDocumentFragment from each argument and write our own
argument list parser.

--
Nick

Re: Validators/Formatters for XNumber?

[David Bertoni <db...@apache.org>]

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