plc4x-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christofer Dutz <christofer.d...@c-ware.de>
Subject Re: [DriverGen] Possible solution for type inheritance
Date Tue, 14 May 2019 10:59:25 GMT
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" <matthias.strljic@isw.uni-stuttgart.de>:

    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: matthias.strljic@isw.uni-stuttgart.de
    Web: http://www.isw.uni-stuttgart.de
    
    -----Original Message-----
    From: Christofer Dutz <christofer.dutz@c-ware.de> 
    Sent: Wednesday, May 8, 2019 3:12 PM
    To: dev@plc4x.apache.org
    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" <christofer.dutz@c-ware.de>:
    
        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
        
    
    

Mime
View raw message