Michael Kay

I'd like to start raising the bar for "nice to have" goodies, certainly. But if it's a clean spec and someone does all the work of providing good test cases,...

>fn:unicode-properties as map(xs:positiveInteger, map(*)) Interesting suggestion. From a user perspective, you would be able to use this as a function, and in addition you would be able to do things...

So there are three potential ways of providing this map: (a) We can provide a system-defined variable `$fn:character-properties` whose value is a map. (b) We can provide a system-defined function...

A couple of possible ways forward: (a) we define a mode of operation in which the interpretation of unprefixed element names in paths is decided dynamically. Specifically, when this mode...

Note that in the current drafts I have already made the change that allows the default element namespace to differ from the default type namespace. (There was really no need...

The idea of treating prefixes as significant goes against the grain simply because we've spent so many years educating people to treat the choice of prefix as insignificant, it would...

@gsnedders Yes, we're well aware of the "wilful violation": that's the crux of this issue, mentioned in the original issue description. My preferred approach is to have a mode of...

My preferred solution to this is as follows. Currently the default namespace for elements and types can be either a namespace URI or absent. I propose that it can take...

Closed by virtue of #1181

The reason for providing position for filter expressions was simply for consistency, it's simpler to define the value of position() than to say that it is undefined, because it would...