Skip to Content.
Sympa Menu

xom-interest - Re: [XOM-interest] XSLTransform setParameter

xom-interest AT lists.ibiblio.org

Subject: XOM API for Processing XML with Java

List archive

Chronological Thread  
  • From: John Cowan <jcowan AT reutershealth.com>
  • To: Elliotte Harold <elharo AT metalab.unc.edu>
  • Cc: xom-interest <xom-interest AT lists.ibiblio.org>
  • Subject: Re: [XOM-interest] XSLTransform setParameter
  • Date: Thu, 10 Feb 2005 10:25:35 -0500

Elliotte Harold scripsit:

> I don't think the name is currently checked in any way to see if it's a
> legal NCName. I need to explore what it would mean to pass a non-name as
> a param value. i.e. what would the stylesheet engine do in that case.

It's impossible to reference such a variable, since variable references
(per XPath 1.0) must be Qnames. I think it is in the spirit of XOM
to check that the passed argument is an NCName.

I also agree that passing separate name and namespace arguments
rather than using Clark notation is the Right Thing. The best thing
about XOM is its conceptual integrity (see _The Mythical Man-Month_).

> The one thing I really agonized over was what the type of the value
> should be. Possibilities include:
>
> 1. A String, which most stylesheet engines can convert to numbers; but
> not booleans; at least not in an obvious way. That is, "false" is true.

I favor this. Most stylesheets probably expect string or numeric
parameters, and it's easy to have the sheet coerce any boolean values
correctly. I think that JAXP uses Object just to punt on the issue.

> 2. Separate methods for String, boolean, and double; thereby covering
> three of the four XPath types.

The trouble with this is that when talking to JAXP you will have to
know for each stylesheet engine how to coerce boolean and double to
Object, and the answer may not always be Boolean and Double.

> 3. Object, which avoids method proliferation and allows other types to
> be passed in if needed by extension functions. Also, at least some XPath
> engines will call toString on unexpected types like java.util.Date so
> they can process them as a string.

The application developer can do that too, and with more type safety.
It would be nice if Java had a Stringizable interface, but it doesn't.

--
John Cowan jcowan AT reutershealth.com www.ccil.org/~cowan
www.reutershealth.com
Any sufficiently-complicated C or Fortran program contains an ad-hoc,
informally-specified bug-ridden slow implementation of half of Common Lisp.
--Greenspun's Tenth Rule of Programming (rules 1-9 are unknown)




Archive powered by MHonArc 2.6.24.

Top of Page