"Wouldn't stripping "all attributes (at any depth) in namespaces other than
http://www.w3.org/2005/xpath-functions" remove the attributes with no
namespace, such as "escaped", "key" and "escaped-key"."

No, those attributes are not in a namespace, therefore they are not in a "namespace other than XXX".

I know this requires the reader to have a very precise understanding of the terminology of the namespaces rec. But I think it's reasonable for us to require this. After all, XSD expects ordinary users to know what <xs:anyAttribute namespace="##other"/> means.

"in what situations will (2) match where (1) would not (and vice versa)?"

As originally written, rule (1) was for typed nodes, and rule (2) was for untyped nodes. More recently, rule (2) changed to delete the phrase "whose type annotation is xs:untyped", which means it also applies to nodes that have been validated against a different schema, provided that validation against the "true" schema would succeed.

Certainly (2) includes many instances where (1) does not apply (e.g. any untyped node), but it's more difficult to find cases where (2) applies and (1) does not.

My recollection from when we last reviewed this is that someone did identify a corner case where this happened. It might have involved something like

<j:array>
  <j:array xsi:type="my-extended-json">
    <j:number/>
    <my:date/>
  </j:array>
</j:array>

where my-extended-json is a type derived by extension from j:arrayType that allows additional child elements. (Perhaps we should have a test for that... Or perhaps the schema should block extension?)

>but it's more difficult to find cases where (2) applies and (1) does not.

I meant of course

>but it's more difficult to find cases where (1) applies and (2) does not.

(In reply to Michael Kay from comment #2)
> >but it's more difficult to find cases where (2) applies and (1) does not.
> 
> I meant of course
> 
> >but it's more difficult to find cases where (1) applies and (2) does not.

I was wondering whether (2) would be sufficient, and (1) could be dropped.

This came from the test case

 
   <test-case name="xml-to-json-045">
      <description>Effect of xsi:type (bug 28181)</description>
      <created by="Michael Kay" on="2015-03-09"/>
      <modified by="Michael Kay" on="2015-06-23" change="Namespace change for bug 28174"/>
      <modified by="Michael Kay" on="2015-07-13" change="By the decision on 28181, this is no longer an error"/>
      <dependency type="spec" value="XQ31"/>
      <test><![CDATA[
        xml-to-json(<number xsi:type="xs:short" xmlns="http://www.w3.org/2005/xpath-functions" 
            xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
            xmlns:xs="http://www.w3.org/2001/XMLSchema">231</number>)
       ]]></test>
      <result>
            <assert-eq>"231"</assert-eq>
      </result>
   </test-case>

Noted in discussion: the way the rules are currently written, if you validate against the schema under rule (1), you are then expected to assess it again against rule (2). If for example there is an attribute xsi:type="nonsense", then schema validation under rule (1) will fail but rule (2) will find no problem.

We want to ensure that a processor only has to assess the input using either rule (1) or rule (2).

I recommend that we change the text 

<old>
The node supplied as $input must be one of the following: [err:FOJS0006]

1. An element node whose name matches the name of a global element declaration in the schema given in C.2 Schema for the result of fn:json-to-xml and whose type annotation matches the type of that element declaration (indicating that the element has been validated against this schema).

2. An element node whose name matches the name of a global element declaration in the schema given in C.2 Schema for the result of fn:json-to-xml, whose type annotation is xs:untyped, and whose content after stripping all attributes (at any depth) in namespaces other than http://www.w3.org/2005/xpath-functions is such that validation against the schema given in C.2 Schema for the result of fn:json-to-xml would succeed.

Note:
The reason attributes in alien namespaces are stripped is to avoid the need for a non-schema-aware processor to take into account the effect of attributes such as xsi:type and xsi:nil that would affect the outcome of schema validation.

3. A document node having exactly one element child and no text node children, where the element child satisfies one of the two conditions above.
</old>

to read:

The node supplied as $input must be one of the following: [err:FOJS0006]

1. An element node whose name matches the name of a global element declaration in the schema given in [C.2 Schema for the result of fn:json-to-xml] ("the schema") and that is valid as defined below:

1a. If the type annotation of the element matches the type of the relevant element declaration in the schema (indicating that the element has been validated against the schema), then the element is considered valid.

1b. Otherwise, the processor MAY attempt to validate the element against the schema, in which case it is treated as valid if and only if validation succeeds.

1c. Otherwise, the processor MUST ensure that the content of the element, after stripping all attributes (at any depth) in namespaces other than http://www.w3.org/2005/xpath-functions, is such that validation against the schema  would succeed.

Note (within 1c):

The process described here is not precisely equivalent to schema validation. For example, schema validation will fail if there is an invalid xsi:type or xsi:nil attribute, whereas this process will ignore such attributes.

2.  A document node having exactly one element child and no text node children, where the element child is valid as defined above.

At the meeting on 2016-09-14, the WG agreed to adopt the proposal in comment #6.
Action A-653-02 has been raised to track this.

The changes have been applied.