[
https://issues.apache.org/jira/browse/DAFFODIL-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olabusayo Kilo reassigned DAFFODIL-1278:
----------------------------------------
Assignee: (was: Olabusayo Kilo)
> DPath expressions involving "." and Runtime SDE bug
> ---------------------------------------------------
>
> Key: DAFFODIL-1278
> URL: https://issues.apache.org/jira/browse/DAFFODIL-1278
> Project: Daffodil
> Issue Type: Bug
> Components: Back End, General, Middle "End"
> Affects Versions: 1.0.0
> Reporter: Mike Beckerle
> Priority: Minor
>
> Consider this schema:
> {code}
> <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>
> {code}
> 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.,
> {code}
> <dfdl:discriminator test="{ if (fn:exists(.) then . eq 3 else fn:false() }"
>
> message="Options-Template-Set/Set-id is not 3" />
> {code}
> 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.
> {code}
> <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>
> {code}
> 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.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
