Defining and operating on types (Was: Re: Why no
> A more compact expression giving the same result is: > > > $item intersect $item/../namespace::* >
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() ) ) ...
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
constructor for namespaces.
As typical for FXSL functions, we can pass this constructor as parameter.
This would require a second parameter for the type... :(
However, *we can pass both the namespace node and its type* via only one parameter:
<xsl:param name="pNodeAndType" as="ConstructingSequence"/>
where "ConstructingSequence" is:
(f:namespace(), strName, strURI)
and could be a more precisely defined (user-defined) type using a SA processor.
Then the type is:
and the node itself is:
f:apply($pNodeAndType, remove($pNodeAndType, 1) )
If we lived in an ideal world then we would be able to write just:
<xsl:param name="pFoo" as="element(f:namespace)"/>
for a definition of a parameter, whose type is a namespace node.
Of course, as of today, this defines only the type of the FXSL constructor for a namespace, not the namespace type itself.
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.
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format