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
    

Reply via email to