I have been looking at Package Prompts and some things are becoming clearer.

Looking at the Remote loader case I found an annoying bug that Aaron has
entered for me:

(Basically it assumes you did not configure SSL and if you did, it
erases the value on a Base package upgrade, or applying a base package
to an existing driver).

So figuring that out cleared up one major issue for me. When you look
at the XSLT, you see these variables that magically have the data. But
I still need to see the XML source to visualize XPATH selections.

So what does the source look like? Well in digging into the Remote
Loader issue I noticed something i missed.

There are 2 objects called PACKAGE-Remote Loader prompts. One in the
Package Catalog, there you see the Transforms (Prompt and Target, Prompt
Transform is to copy the values from the XML into the display prompts
when you see when you add the Package. Then Target Transform is to
apply any changes you want after the user customizes it and copy to the

In the Remote Loader case this makes sense. The attr in eDir is:
REMOTE(hostname='ip of RL' port='8190' kmo='SSL CertificateIP'

But Designer parses this into 4 fields. Hostname, Port, KMO, and Other.

So it actually stores it as eDir stores I suspect, so the Prompts
transform has to read it, pick it into 4 parts, to display it. Then the
Target Transform has to put it back together into its single string form.

The problem there is that the KMO and Other field were forgotten in the
transforms. (And as far as I can tell in most base packages. I only
tested AD and GW, but I suspect all of them have this issue).

Now, in doing this I found the second object, PACKAGE-Remote Loader
prompts under the driver, that is NOT a DirXML-Resource, with
DirXML-ContentType of PackagePrompt (as it is in the Package Catalog),
and it contains what appears to be the XML that is the source for the
Prompts Transform to read.

So here I was, there you go, now I can understand it! This is great.

Except I then went to look at a GCV Prompt configuration. The second
object under the driver, that for RL had what appeared to be the proper
XML to work on, it shows:

<definition display-name="GCV name" name="gcv.name" type="string">
<value xml:space="preserve">Some\Value</value>

Ok, that makes sense, its a GCV object, so you would expect it to
contain GCV XML.

But then I look at the Transform that is the template in Designer, and
it looks more like:

<xslaram name="propertyWizard"/>
<!-- pre-populate prompts with existing values -->
<xsl:template match="definition/value">
<xsl:variable name="name" select="../@name"/>
<xsl:variable name="curVal">
<xsl:when test="$curDoc//ds-value[../@ds-attr-name=$name]/text()">
<xsl:value-of select="$curDoc//value[../@name=$name]/text()"/>

So it starts with a template matching definition nodes with value nodes
underneath it. (I.e. populated values).

But that test of $curDoc//ds-value[../@ds-attr-name=$name]/text() is
looking at a <ds-object> object style XML.

So what does $curDoc look like? The example in the Template comment is
for Driver configuration (Which admittedly shares a DTD with GCV's).

Where would I find a way to get the example of $curDoc for an arbitrary
Prompt object?