Consider this schema:

 <xs:element name="Set-id">

                <xs:simpleType>

                    <xs:annotation>

                        <xs:appinfo source="http://www.ogf.org/dfdl/">

                            <dfdl:discriminator 

                                                test="{  . eq 3  }"

                                                message="Options-Template-Set/Set-id is not 3" />

                        </xs:appinfo>

                    </xs:annotation>

                    <xs:restriction base="int16">

                        <xs:enumeration value="3" />

                    </xs:restriction>

                </xs:simpleType>

            </xs:element>

The above is one branch of an xs:choice.

Now according to DFDL spec section 9.5.2:
--------------------
9.5.2 Discriminators with testKind 'expression'

When parsing, an attempt to evaluate a discriminator must be made even if preceding statements or the parse of the schema component ended in a processing error.

This is because a discriminator's expression could evaluate to true thereby resolving a point of uncertainty even if the complete parsing of the construct ultimately caused a processing error.

Such discriminator evaluation has access to the DFDL Infoset of the attempted parse as it existed immediately before detecting the parse failure. Attempts to reference parts of the DFDL Infoset that do not exist are processing errors.
-----------------------------

So, even if the parse of the Set-id element fails, we're going to evaluate this discriminator anyway.

That means in the expression, the subexpression "." has no value.

But in Section 23, the DFDL Spec says:

DFDL implementations MUST comply with the error code behaviour in Appendix G of the XPath 2.0 spec and map these to the correct DFDL failure type. All but one of XPath's errors map to a schema definition error. The exception is XPTY0004, which is used both for static and dynamic cases of type mismatch. A static type mismatch maps to a schema definition error, whereas a dynamic type mismatch maps to a processing error. A DFDL implementation should distinguish the two kinds of XPTY0004 error if it is able to do so, but if unable it should map all XPTY0004 errors to a schema definition error.

The implications of that are that when an expression has no value, it is a Schema Definition Error, not a Processing Error.

A Schema Definition Error doesn't backtrack. It is fatal.

One is supposed to wrap paths that may not exist with the fn:exists(....) function and test explicitly if they exist. That way one does not get these runtime SDEs.

But it makes no sense to have to do that on the "." expression. E.g.,

  <dfdl:discriminator test="{ if (fn:exists(.) then . eq 3 else fn:false()  }"

                                                message="Options-Template-Set/Set-id is not 3" />

That's just silliness. (and doesn't work.)

The "." aka context node expression, when used alone, must get special treatment in discriminators.

Note: there is a workaround for this bug. One can move the discriminator to after the Set-id element so that the parsing of the Set-id element must be successful before the discriminator is encountered.

 <xs:element name="Set-id">

                <xs:simpleType>

                    <xs:restriction base="int16">

                        <xs:enumeration value="3" />

                    </xs:restriction>

                </xs:simpleType>

            </xs:element>

<xs:sequence>

   <xs:annotation>

                        <xs:appinfo source="http://www.ogf.org/dfdl/">

                            <dfdl:discriminator 

                                                test="{  ./Set-id eq 3  }"

                                                message="Options-Template-Set/Set-id is not 3" />

                        </xs:appinfo>

                    </xs:annotation>

</xs:sequence>

The above works fine.

An easy partial "fix" that would at least let people make progress would be issuing a subset-limitation error and disallow use of "." alone in discriminators on elements. This would force authors to rewrite their schema to put the discriminator later as in the workaround.

Ultimately, the treatment of "." in discriminators is a special case that the DPath compiler and runtime must handle.