> A more compact expression giving the same result is:
>
>
>     $item intersect $item/../namespace::*
>

Only works for a namespace node that has a parent.

Parentless nodes are strange beasts -- the namespace parentless node
the strangest among them.

First of all, they do not come from (cannot be found in) any existing
xml document. So speaking about parentless nodes we are in a sense
like particle physicists concentrating on the physical particles alone
and not interested in the bigger picture.

I'd call a parentless namespace node "candidate namespace instance"
because there are no nodes in this namespace. In a sense it is not yet
"fully produced", not "born".

We alone have created this namespace node and we are responsible for
handling it around and knowing its type among other things.

However, it's still a pity we cannot specify its type when passing
such a node to a function. If this function needs to determine the
type of the parentless namespace node, then it must do something like
this:

   if ( $item instance of node()
          and not($item instance of attribute()
                    or $item instance of comment()
                    or $item instance of document-node()
                    or $item instance of element()
                    or $item instance of processing-instruction()
                    or $item instance of text() ) ) ...

but even this code may become incorrect in the future, should a new
Spec define a new node-type for which there's also no type-test. Then
the above code will only determine that the type of the node is one of
the two node-types that have no type-test.

One way is for us to hope that this will be covered by a new
exslt:object-type() in the future.

Another, direct way is described below:
We can go further and say that because the type of an item is fully
determined by its constructor function, then we can use its
construction function as its type.

In the case of a namespace node, FXSL can provide a wrapper around the
<xsl:namespace> instruction and thus an

However, *we can pass both the namespace node and its type* via only
one parameter:

Of course, as of today, this defines only the type of the FXSL
constructor for a namespace, not the namespace type itself.

On a similar topic, recently Florent Georges working on FXSL provided
a way to copy items having user-defined types and to preserve their
types during this copying.

While this is an excellent and useful result, this still doesn't allow
a generically-typed higher-order-function to deduct the type of its
user-defined-typed argument -- only to do type-preserving operations
on it.

Also, Florent's technique could not be applied for user-defined types
derived from xsl-schema basic simple types.

Passing a constructing sequence, containing both the type constructor
function and the sequence of arguments needed to instantiate the item
solves these issues and gives the generically-typed HOF full control
and knowledge of the argument in all cases. For example, in addition
to type-preserving copying, it will now be possible to construct new
items having the same type as the argument.

--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk