plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <>
Subject Re: [DriverGen] Possible solution for type inheritance
Date Wed, 08 May 2019 13:12:05 GMT
Hi all,

I also just had another idea ...

No matter how we define the schemas we'll always have one problem in the end ... how to map
some type like an "unsigned-16-bit-integer" into something the language can understand.
So we were thinking of some Language adapters ... now this could handle the mapping to code,
but we don't have control over how these types are defined in the protocol specifications.
Each protocol spec currently defines all the types it needs locally. 

Now I had an idea that might help solve both problems:
- I create a "plc4x-dfdl" schema which contains definitions for all of the base types
- We use and import this schema into dfdl protocol specs to have the same base-line in all
plc4x protocol specs
- When we write new language packs, we do so by providing implementations for all of the types
in the plc4x-dfdl schema

Guess this should be a pretty clean definition of what plc4x provides, what protocol engineers
need to define in their drivers and what language engineers need to provide in their language


Am 08.05.19, 11:29 schrieb "Christofer Dutz" <>:

    I think while refactoring the DFDL schemas a little more, I came up with an idea on how
we can support inheritance with DFDL:
      *   In all cases with inheritance, we have a “choice” element in the schema
      *   Some sort of “type” element is parsed before the choice element itself
    Now the idea is that if a type contains a choice, that the name of the base class of all
sub-types is based on the name of the element that contains the choice.
    <xs:complexType name="S7RequestMessage">
            <!-- Reserved value always 0x0000 -->
            <xs:element name="reserved" type="s7:short" fixed="0"/>
            <xs:element name="tpduReference" type="s7:short"/>
            <xs:element name="parametersLength" type="s7:short"/>
            <xs:element name="payloadsLength" type="s7:short"/>
            <xs:element name="parameters" minOccurs="0"
                        dfdl:lengthKind="explicit" dfdl:lengthUnits="bytes" dfdl:length="{../parametersLength}"
                        dfdl:occursCount="{if(../parametersLength gt 0) then 1 else 0}">
                        <xs:element name="parameter" maxOccurs="unbounded">
                                    <xs:element name="type" type="s7:byte"/>
                                    <xs:choice dfdl:choiceDispatchKey="{xs:string(type)}">
                                        <xs:element dfdl:choiceBranchKey="240" name="s7GeneralParameterSetupCommunication"
                                       <xs:element dfdl:choiceBranchKey="4" name="s7RequestParameterReadVar"
                                        <xs:element dfdl:choiceBranchKey="5" name="s7RequestParameterWriteVar"
    In this case we would have an S7RequestMessage type which contains a property “parameters”
of type “List<Parameter>”.
    Parameter (containing a choice) would be an abstract class with an abstract “getDenominator”
    S7GeneralParameterSetupCommunication would extend Parameter.
    You think that’s a path to go? … Had to add some artificial elements in order to set
the boundaries of the types.

View raw message