Hi all, while pursuing this path I did quite some refactoring to the DFDL schema of the S7 protocol. But no matter how I do it, the resulting number of types would be enormous. This is due to the fact that it is impossible to define a real type hierarchy. Everything is flat and if I try to come up with a way of representing these types by the means DFDL has to offer it's sort of always: Works in most of my cases, but impossible for the last ...
I'm pretty much exhausted with this approach and I think we should consider others ... however which ones? I wrote down some ideas here: https://cwiki.apache.org/confluence/display/PLC4X/Formats+for+defining+the+dataformat It would be great if we could discuss things here cause we desperately need to solve this problem. Chris Am 10.05.19, 08:45 schrieb "Strljic, Matthias Milan" <[email protected]>: Hi Chris, more sorry about writing late. I would agree with Julian there, with the addition that for the standard types there might simply be a DFDL provided, which could simply be included? Greetings Matthias Strljic, M.Sc. Universität Stuttgart Institut für Steuerungstechnik der Werkzeugmaschinen und Fertigungseinrichtungen (ISW) Seidenstraße 36 70174 Stuttgart GERMANY Tel: +49 711 685-84530 Fax: +49 711 685-74530 E-Mail: [email protected] Web: http://www.isw.uni-stuttgart.de -----Original Message----- From: Christofer Dutz <[email protected]> Sent: Wednesday, May 8, 2019 3:12 PM To: [email protected] Subject: Re: [DriverGen] Possible solution for type inheritance 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 templates. Chris Am 08.05.19, 11:29 schrieb "Christofer Dutz" <[email protected]>: Hi, 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. Example: <xs:complexType name="S7RequestMessage"> <xs:sequence> <!-- 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:occursCountKind="expression" dfdl:occursCount="{if(../parametersLength gt 0) then 1 else 0}"> <xs:complexType> <xs:sequence> <xs:element name="parameter" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="type" type="s7:byte"/> <xs:choice dfdl:choiceDispatchKey="{xs:string(type)}"> <xs:element dfdl:choiceBranchKey="240" name="s7GeneralParameterSetupCommunication" type="s7:S7GeneralParameterSetupCommunication"/> <xs:element dfdl:choiceBranchKey="4" name="s7RequestParameterReadVar" type="s7:S7RequestParameterReadVar"/> <xs:element dfdl:choiceBranchKey="5" name="s7RequestParameterWriteVar" type="s7:S7RequestParameterWriteVar"/> </xs:choice> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> 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” method. 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. Chris
