More requirements for type information

[michaelhkay]

See original issue #148.

There have been requests for further type information beyond that supplied by the four new functions

node-kind()
atomic-type-annotation()
node-type-annotation()
schema-type()

One of the requests was to be able to test if an item is a map, and array, some other function, a node, or an atomic value.

This could perhaps be done by broadening node-kind() to a function item-kind() that returns "map" for a map, "array" for an array, etc. We could also return the result in item-type syntax, say map(*) or array(*) or function(*).

What else is needed?

[ChristianGruen]

An fn:type function (or fn:type-string, or similar) could return a sequence of strings, mirroring the hierarchy:

• fn:type(1) could return: xs:integer, xs:decimal, xs:anyAtomicType, item()
• fn:type(<x/>) could return: element(x), element(), node(), item()
• fn:type([ 1 ]) could return: array(xs:integer), array(*), possibly fn(*), item()
• fn:type(count#1) could return: fn(item()*) as xs:integer, fn(*), item()

Obviously, the output cannot be complete for function items: Maybe we can ignore types like fn(item()*) as xs:anyAtomicType or fn(xs:int) as xs:integer for count#1 and only output a type string for the most general type for all parameters and the most specific type for the returned value?

The function would allow people to do things like if(type($x) = 'xs:integer') ..., or if(some(type($x), contains(?, 'map'))) .... The output of fn:path is often processed in a similar way.

Maybe it will be easier for trivial use cases to only return the most specific type by default. We could add an options parameter to return alternatives, and control further details.

[line-o]

@ChristianGruen your examples implies the signature fn:type($item as item()) as xs:string+

This does simplify the specification a lot.

I would argue that it should be fn:type($item as item()?) as xs:string+ where fn:type(()) could return an empty sequence.

So it is safe to use in cases where existence of a value is not guaranteed.

I also explored how the output of fn:type as laid out above could be used to find a common type among sequences of items and created a gist of my proof of concept

I do not claim correctness but want to share that here to discuss further and also show the applicability of @ChristianGruen's approach.

[line-o]

What else is needed?

fn:item-kind would have to include atomic types.

The use-case is to give developers a way to answer the question "What is the type of this item?".

[ChristianGruen]

I would argue that it should be fn:type($item as item()?) as xs:string+ where fn:type(()) could return an empty sequence.

If we allow the input to be optional, I think we should rather return the empty sequence instead of an empty-sequence() string. Otherwise, we would mix up item types and sequence types.

[line-o]

Yes, this is exactly what I meant.

[michaelhkay]

What should item-kind() return for atomic items? The primitive type? The most specific non-anonymous type?