RE: [F&O] fn:type() proposal (Was: [XSLT 2.0] Is it possible to d isplay the type of a node / value / variable?)

My instinct on this is that I would like to do introspection properly, by
making types available as first class objects, and that is beyond the scope
of this version. Returning the type names as strings is a half-hearted
solution that only solves a small number of use cases, if no further
information is available about the types. In the case of anonymous types the
information is almost useless, and means we have to decide questions about
the nature of implementation-assigned type names that are best left
undefined.

Michael Kay


> -----Original Message-----
> From: Jeni Tennison [mailto:jeni@jenitennison.com] 
> Sent: 21 May 2003 18:35
> To: public-qt-comments@w3.org
> Subject: [F&O] fn:type() proposal (Was: [XSLT 2.0] Is it 
> possible to display the type of a node / value / variable?)
> 
> 
> 
> Michael Rys wrote:
> > You can use the instance of and typeswitch expressions to 
> inspect the 
> > type.
> >
> > Exposing the type name is a feature of the debugger in my 
> opinion and 
> > not a language feature.
> 
> Currently you can't do useful things like:
> 
>   1. See if two nodes have the same type (which would be particularly
>      useful if we want to enable users to create their own functions
>      for testing node equality)
>      
>   2. Select all nodes of a particular type, where that type is
>      specified via a parameter
> 
>   3. Perform a transformation that annotates every typed element with
>      its type by adding an xsi:type attribute
> 
> These are the kinds of operations that XSLT users do quite 
> commonly with node *names*. It seems reasonable to assume 
> that XSLT users will want to do them with node types as well.
> 
> I can see fewer uses for a function that exposes the type of 
> an atomic value, but there are cases outside debugging. One 
> use case would be where you wanted to create an element 
> wrapper around a particular value and use xsi:type to 
> indicate the type of the value held by the new element.
>      
> So I propose a fn:type() function as follows:
> 
> ---
> fn:type($arg1 as item()?) as xs:QName*
> 
> If $arg1 is the empty sequence, fn:type() returns an empty sequence.
> 
> If $arg1 is an element or attribute node, fn:type() returns a 
> sequence of expanded-QNames. The first expanded-QName is the 
> dm:type() of the node, the second is that type's base type 
> from the in-scope schema definitions, the third is that 
> type's base type and so on up the type hierarchy. The last 
> expanded-QName in the sequence is xs:anySimpleType for an 
> attribute node and xs:anyType for an element node.
> 
> If $arg1 is a text node, fn:type() returns the expanded-QName 
> xdt:untypedAtomic.
> 
> If $arg1 is any other kind of node, fn:type() returns an 
> empty sequence.
> 
> If $arg1 is an atomic value, fn:type() returns a sequence of 
> expanded-QNames. The first expanded-QName is the type of the 
> atomic value, the second is that type's base type from the 
> in-scope schema definitions, the third is that type's base 
> type and so on up the type hierarchy. The last expanded-QName 
> in the sequence is xdt:anyAtomicType.
> ---
> 
> Cheers,
> 
> Jeni
> 
> ---
> Jeni Tennison
> http://www.jenitennison.com/
>

Received on Thursday, 22 May 2003 11:01:10 UTC