Removal of redundant extendable (number of interfaces) external interface definitions

[AlexTxen]

It should be considered to remove redundant external interface definitions in AML library, where it is intended to have more interfaces in 'InstanceHierarchy' (real data/document export), than in AML library definition.

For example "OR" EFB currently contains "X1" and "X2" inputs in AML library. There is (currently unofficial) convention, that in real export/import data X1...Xn can be used.

Proposal is to remove redundant ...[2] definitions (in example with "OR" gate it would be removal of X2 external interface), since it is not providing any useful information about AML library usage. Library usage (where external interface names ending by number/'1') should be described in supporting documentation, like it was done in 'krafla' branch (ce4a15b).

[Erik0x42]

I agree that some supporting documentation should describe extensibility, and maybe we also need a new attribute to declare extensibility, since not all cases of X1, X2 are extensible.

But in my opinion all of the X2 terminals should be kept (as they are as of version 0.0.10), because X2 is always used (100% of cases). None of the EFBs can be used with only X1, they all require at least X2.
This also supports use of the AML Library as an actual library - in various SCD/AML tools - to instantiate types from, with a default configuration ready for use.

Terminals that are used in less than 100% of scenarios might be candidates for removal, like ExternalInterface "Y2" on "SequenceElementLibrary/StandardSequenceElementClass/Step".

[PatrickRasche]

I don't think that it is a feasible to have a mixture between dedicated classes for terminals like X1/X2 and a common class for all additional pins. What about an OR gate with more then 2 inputs? We would have a definition like that (I've skipped the last level for the terminals 3 to n, of course there could be an additional "X" in the end):

• X1 -> InterfaceClassLibrary/NorsokSignalClass/In/DI/X/X1
• X2 -> InterfaceClassLibrary/NorsokSignalClass/In/DI/X/X2
• X3 -> InterfaceClassLibrary/NorsokSignalClass/In/DI/X
• Xn -> InterfaceClassLibrary/NorsokSignalClass/In/DI/X

This is completely confusing. Either we need a class definition for all possible pins (even though these would be redundant classes) or we have to skip it for each terminal class.

[Erik0x42]

Good point, see issue #3

[AlexTxen]

As a part of #3 implementation in 6bbd932, specific classes were removed.
Consequently, additional terminals can be inherited from same class, as predefined terminals:

X1: InterfaceClassLibrary/NorsokSignalClass/In/BinaryIn
X2: InterfaceClassLibrary/NorsokSignalClass/In/BinaryIn
X3: InterfaceClassLibrary/NorsokSignalClass/In/BinaryIn
Xn: InterfaceClassLibrary/NorsokSignalClass/In/BinaryIn

Initial proposal on removal of predefined numbered terminals (e.g. 'X2') is now not necessary. Issue can be closed.