W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2003

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

From: Michael Rys <mrys@microsoft.com>
Date: Wed, 21 May 2003 18:05:27 -0700
Message-ID: <5C39F806F9939046B4B1AFE652500A3A05598E8B@RED-MSG-10.redmond.corp.microsoft.com>
To: "Jeni Tennison" <jeni@jenitennison.com>, <public-qt-comments@w3.org>

> 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)

[Michael Rys] Node equality is an overloaded term. Do you mean identity,
structural equality etc?

>   2. Select all nodes of a particular type, where that type is
>      specified via a parameter

[Michael Rys] Correct. We should leave some of this to vNext. The specs
are already too big in my opinion to see many complete XQuery
implementations in the beginning. Thus having some functionality not
available today should not be a problem.

There is also an issue about how to expose a type name, given that you
have three classes of types: element types, attribute types, and types
(complex or simple). 
 
>   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.

[Michael Rys] Ok. I see your use cases. I still think that this is a
feature that can wait.

> 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 Wednesday, 21 May 2003 21:05:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:14:24 GMT