plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Feinauer <>
Subject Re: [DriverGen] Possible solution for type inheritance
Date Wed, 08 May 2019 13:20:38 GMT
Hi Chris,

sorry, for just responding now.
I guess you are the only one that deeply involved in the DFDL Schema and stuff.
I only scratched at the surface and guess it is incredibly powerful.
But as everybody knows... with great power complex great complexity.

So, on one hand, your suggestion sounds reasonable, to have some kind of "base" definition.
But on the other hand I mislike the "central" nature of that.
I meant, there are some standards which will be used by all drivers like units, ints, C-Strings
and so with LE/BE but other than that I'm pretty sure (but only a feeling, nothing I could
prove) that every protocol we touch brings something we did not think about yet.

So I personally would prefer if we do these types directly in the protocol, and perhaps simply
with a clear description how to deserialize or so (byte shifts, bit shifts, ...).
Otherwise we have some kind of coupling behind all these drivers through the backdoor and
in the worst case we would make one driver fall silently, because we fix some kind of bug
with the types in another one or something.

Don’t we have some possibilities to do something like that?


Am 08.05.19, 15:12 schrieb "Christofer Dutz" <>:

    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