Created attachment 324756 [details] [review]
Patch implementing the suggestion

I'm describing this in terms of the command-line xsltproc utility, but the issue is in libxslt rather than the command-line front-end.

Consider a template that uses a parameter with a prefixed name, eg:foo:

  <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                  xmlns:eg="http://example.com/" version="1.0">
    <xsl:param name="eg:foo"/>
    <xsl:output method="text"/>
    <xsl:template match="/">
      <xsl:value-of select="$eg:foo"/>
    </xsl:template>
  </xsl:stylesheet>

Setting this parameter from the command-line is just like setting an unprefixed parameter:

  xsltproc --stringparam eg:foo Something template.xslt input.xml

That does the job fine.  But the namespace prefix is really an implementation detail of the XSLT, not part of its public interface.  The public interface to that parameter should be the namespace name and local part, per the last paragraph of §4 of Namespaces in XML 1.0 (Third Edition):

  "Note that the prefix functions only as a placeholder for a namespace 
  name. Applications SHOULD use the namespace name, not the prefix, in 
  constructing names whose scope extends beyond the containing document."

Therefore, as an alternative to specifying a lexical QName, I think libxslt should allow parameters to be specified by namespace name and local part.  Saxon allows this with the following syntax:

  java net.sf.saxon.Transform -s:input.xml -xsl:template.xslt \
    "{http://example.com/}foo='Something'"

The attached patch implements the same interface in libxslt.  With the patch I can still run the current xsltproc command, but I can also run:

  xsltproc --stringparam {http://example.com/}:foo Something \
    template.xslt input.xml

The patch also updates the --help message to xsltproc to mention this.

If you'd like me to update the patch so that it also (or only) supports the URIQualifiedName style from XPath 3.0, I'd be happy to do so.

My motivation for requiring this is that I'm writing software that will allow a user to select at runtime the particular template to use, according to stylistic preferences and nationalisation requirements.  These templates will commonly be provided by third parties writing to a specification that just states the QName of the parameters and the fact that the output must conform to a particular HTML profile.  The prefix bindings aren't currently (and shouldn't in my opinion become) part of that specification.