For named types would we use a construct ??~type(FOO) and for atomics ??~xs:integer or even ??~integer given xs: default?

I'm working backwards from the common case of selection using a record type to the more general case (just as path expressions focus on having convenient syntax for the common cases).

But I think we could achieve something like

KeySpecifier ::= .... | "~" SequenceType

but allowing the SequenceType to be in parentheses, or perhaps requiring it to be in parentheses if there is an occurrence indicator, which would make it "~" ( ItemType | "(" SequenceType ")")

Let’s assume we have XML encoded either in a document or in a “structured item” (which is how we occasionally call maps/arrays internally). Are the following two expressions comparable to some extent / would they both return the element <a/>?

let $doc := document { <a/> }
return $doc / element()

let $struct := [ <a/> ]
return $struct ?~ element()

If we wanted to try to make the syntax accessible to non-experts, would it be fair to present / and ?~ as somewhat equivalent?

It would be great if we could agree on a collective term for "maps and arrays". "Structured item" feels too generic to me. I've toyed with terms like "tabulation", "tabula", "composition", "dataset", "compendium", "aggregate".

Perhaps "combo"? It's best to have a word that stands out from the crowd if we can't find one whose meaning is self-explanatory.

With "/", the RHS is always selecting nodes, and we are primarily selecting nodes by nodekind and name, occasionally by type. So we can write a/element(*, xs:integer) but we rarely need to, because element names usually provide the handle that we need. With JSON, we don't have element names, so selecting by type becomes a much more common requirement.

The syntax a/element() works only because element is reserved as a function name. We don't have the luxury of reserving any names after "?" in the same way. Logically we could think of a/element() as an abbreviation for a/~element(), where the ~ can be omitted because element is a reserved name.

Is there any restriction on using something like element as an ItemType name? (I can only see restrictions against using atomic type names). If the are none, then a/~element would be legal (assuming suitable declaration), but somewhat confusing!

There's no restriction on using bare NCNames as atomic type names or declared item type names. It's quite legal today to do a/element(element, element).

My first reaction is to use syntax like:

?? X ?? Y::map

or

?? X ?? Y[isMap(.)]

or

? X ?? maps(Y)

or

?? X ?? Y[hasKeys(.)]

Or why not:

?? X ?? map::Y

I am against introducing new, unreadable symbols in the already quite messed symbol-set we are using at present.

Readability must have much higher priority in our design than introducing new, fancy (cryptic) symbols.

And of course, if the proposal for Total Maps is accepted,

Then any constant non-map value can be represented-as / coerced-to a map:

map {
'\' : ()
}      (: produces the empty sequence  for any lookup:)

We definitely need a convenient way to do the equivalent of $map??record(long, lat).

We can't use that syntax because ??record(X) is legal and means something else.

I've toyed with all sorts of alternatives and listened to suggestions, and I can't come up with anything better than ~type. So I'm going to raise a PR to that effect.

I'm also inclined to reinforce the association of ~ with a type test by allowing A ~ T as a synonym of instance of, with the unary form ~ T meaning . ~ T; by using ~ in place of type in XSLT type patterns. This would allow, for example:

<xsl:switch select="$x">
   <xsl:when test="~xs:integer" select="..."/>
   <xsl:when test="~xs:float" select="..."/>
   <xsl:when test="~xs:double" select="..."/>
</xsl:switch>

and
<xsl:template match="~record(a, b)">...</xsl:template>

but perhaps that should be a separate proposal.

I can't come up with anything better than ~type.

My preference is very much more for:
??<-<map>->,
??<-<integer>->
Or
??$<map>,
??$<integer>
Or anything that is easy to read and well-protected from a single key-mistyping that results in another correct lexical representation.