XOM API for Processing XML with Java

["Michael Kay" <mike AT saxonica.com>]

Everyone designing XPath APIs has agonized over this problem, and most of
them have ended up using "Object" as the type. Not very satisfactory, but
it's hard to come up with a better answer. When you cross language
boundaries, type checking tends to break down.

I suspect that most XSLT engines will ignore a supplied parameter if it
doesn't match one that's declared in the stylesheet. The spec, however,
leaves this decision to the API designer.

JAXP chose to pass a namespaced parameter name as a single string in Clark
notation. Since namespaced parameter names are rather unusual in practice,
that has the benefit that it adds less clutter to the API. It's not clear
that you are doing anyone a favour by making a different decision here.

Michael Kay
http://www.saxonica.com/ 

> -----Original Message-----
> From: xom-interest-bounces AT lists.ibiblio.org 
> [mailto:xom-interest-bounces AT lists.ibiblio.org] On Behalf Of 
> Elliotte Harold
> Sent: 10 February 2005 12:05
> To: xom-interest
> Subject: [XOM-interest] XSLTransform setParameter
> 
> I've added some API to the XSLTransform class to allow 
> clients to pass 
> parameters (values that override xsl:param elements) to XSL 
> engines and 
> stylesheets. The API is fairly simple:
> 
> public void setParameter(String name, Object value)
> public void setParameter(String name, String namespace, Object value)
> 
> Passing a null value removes the parameter. There's not currently any 
> getParameter method. I can add one if anybody ever needs it, or if 
> there's a compelling use case. However, I just prefer not to 
> clutter the 
> API until I know there's a need.
> 
> 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.
> 
> 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.
> 
> 2. Separate methods for String, boolean, and double; thereby covering 
> three of the four XPath types.
> 
> 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.
> 
> I'm about 80% convinced that Object is the right type here, but if 
> anyone wants to argue otherwise, go ahead. I might still be convinced 
> otherwise. I still don't like the idea of passing in an 
> arbitrary object 
> that the stylesheet might not be prepared to handle. And of course if 
> anybody else spots any other problem with this API that I haven't yet 
> seen, holler. These are just my initial thoughts. None of this is 
> written in stone yet.
> 
> -- 
> Elliotte Rusty Harold  elharo AT metalab.unc.edu
> XML in a Nutshell 3rd Edition Just Published!
> http://www.cafeconleche.org/books/xian3/
> http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/
> ref=nosim
> 
> _______________________________________________
> XOM-interest mailing list
> XOM-interest AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/xom-interest
>