[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
f:namespace()
constructor for namespaces.
As typical for FXSL functions, we can pass this constructor as parameter.
This would require a second parameter for the type... :(
<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:
$pNodeAndType[1]
and the node itself is:
f:apply($pNodeAndType[1], 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.
[xsl] Defining and operating on types (Was: Re: [xsl] Why no namespace node KindTest?)
Subject: [xsl] Defining and operating on types (Was: Re: [xsl] Why no namespace node KindTest?) From: "Dimitre Novatchev" <dnovatchev@xxxxxxxxx> Date: Sun, 27 Aug 2006 08:58:15 -0700 |
> 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
f:namespace()
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:
$pNodeAndType[1]
and the node itself is:
f:apply($pNodeAndType[1], 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.
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Client-side XSLT processi, Ragulf Pickaxe | Thread | Re: [xsl] Defining and operating on, Florent Georges |
Re: [xsl] Client-side XSLT processi, Ragulf Pickaxe | Date | Re: [xsl] Defining and operating on, Florent Georges |
Month |
Keywords