Use actual type name, instead of nm key, for derived type checks.

[ElectronicRU]

Otherwise, it fails when we're checking against an alias type, e.g. a sub-element that has a type assigned in the schema.

[willemdj]

Can you give an example of the problem that you are solving with this change?

[ElectronicRU]

Sure! Here's a BPMN document I was trying to parse. (Attached is also a compiled schema). The document provides a bpmn:timeCycle, which is normally of the type bpmn:tExpression, but explicitly specifies the type as bpmn:tFormalExpression.

The type alias for timeCycle element is tTimerEventDefinition-timeCycle, while the actual type is tExpression. Therefore, the check for it being a subtype fails, where it should succeed. BPMN20.term.txt 01.bpmn.txt

PS: Hm, on a second thought, I don't think the HRL generated actually conforms to that -- the Dialyzer type annotations seem to disallow extension types. Here's the relevant snippet from BPMN XSD:

    <xsd:element name="timerEventDefinition" type="tTimerEventDefinition" substitutionGroup="eventDefinition"/>
    <xsd:complexType name="tTimerEventDefinition">
        <xsd:complexContent>
            <xsd:extension base="tEventDefinition">
                <xsd:choice>
                    <xsd:element name="timeDate" type="tExpression" minOccurs="0" maxOccurs="1"/>
                    <xsd:element name="timeDuration" type="tExpression" minOccurs="0" maxOccurs="1"/>
                    <xsd:element name="timeCycle" type="tExpression" minOccurs="0" maxOccurs="1"/>
                </xsd:choice>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>

    <xsd:complexType name="tFormalExpression">
        <xsd:complexContent>
            <xsd:extension base="tExpression">
                <xsd:attribute name="language" type="xsd:anyURI" use="optional"/>
                <xsd:attribute name="evaluatesToTypeRef" type="xsd:QName"/>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType

Is this behaviour intended?

[ElectronicRU]

After thinking some more, I realize that this pull request does not resolve the issue, nor I think the issue could unfortunately be resolved at all under current object model of erlsom. Closed.

[ElectronicRU]

@willemdj I am wondering, how hard would it be, in your opinion, to implement a kind of "type container" thing for cases like that? IE a structure that holds a #tExpression{} / #tFormalExpression{}, in this case. I'd love to go forward with do ing it myself, but the codebase is far from simple, unfortunately, so I'd appreciate some pointers - I'm happy to do the test suites for it, too!