The OMG LECIS specification, it has come to light, is in some cases either
extending or being constrained by the existing ASTM LECIS specification
which is not due for review until next year.

As Fred Waskiewicz, Director of Standards, pointed out this is a more
substantive issue with several possible resolutions. The simplest of which
is "to have the FTF complete OMG LECIS for publication and have a RTF (or
more probably, a RFP) address the alignment issues". I suppose the question
might then be raised would publication at this stage serve any useful
purpose if we want to ensure ASTM and OMG standards are completely aligned
via another RFP or wider consultative process?

see discussion

The specification does not always define what happens in case I send a primary command to the SLM Main Unit (which would be delegated also to all Sub Units) but the main unit is not in the correct state.

• The Main Unit should return the result code MAIN_STATE_INCORRECT and not call any Sub Units.
  T
  This is defined for some primary comamnds, but we should include a general statement into the spec to make this clear

Add explanatory paragraph on page 2-10 at the end of chapter 2.3.5

I would suggest a name change in the SLM IDL type "ELocalRemote_ArgType"

enum ELocalRemote_ArgType

;

We should change RELEASE_CONTROL to RELEASE_CTRL.
This would be a more consistent naming convention.

Consistent naming conventions are agreed to be desirable

We should discuss, if we need a parameter interactionID for primary SLM commands like "init()".

see discussion

The enum EResultCode in the SLM IDL (page 2-7 and 8-2) contains a typo:

SUBUNIT_UNKOWN should be SUBUNIT_UNKNOWN;

Correct typo.

We do not need a parameter "unit_id" in the ILECI operation "local_remote_req()".The request is always handled by the main unit.

This is correct in the text (page 2-11), but not in the SLM IDL.

The figure 2-4 (ILECI interface) is also not correct in this case.

Correct Figure 2-4

In Figure 2-3 "Sub-Unit State Model" is the transition from SUB_PROCESSING to SUB_IDLE not visible.

This is a problem with the Word graphic. In the original UML model we have this transition.

graphic to be corrected

slm_event():
The parameter lists for DATA_DIRECT and DATA_LINK are not in the same order (dataid, dataformatid and sequence counter)

The argument list for DATA_DIRECT:

• A Sequence of Octet containing the data values.
• A string with the dataformatID
• A string with the dataID
• A long value with the sequence counter

The argument list for DATA_LINK:

• A string with the data ID.
• A string with a sequence counter.
• A string with the dataformatID.
• An EDataLinkType defining the link type (Listing 25).
• A string with the link value.

see above

We don't have a timestamp in the slm_event() method of the ITSC_Callback interface (page 2-21)

I think, this would be usefult to determine when an event was created by the slm

Create a timestamp in the slm_event method of the ITSC_Callback

In SLM IDL: We are missing the control state ESTOPPED in

enum EMainCtrlState

It is in the text (page 22) but not the IDL. definition!!

see discussion

Java JDK1.4- IDL compiler complained in SCD IDL, that INIT is a keyword. We should use escaped identifier or change the name.

2. Java JDK1.4 IDL compiler complained in SLM IDL, that LOCAL is keyword.We should use escaped identifier or change the name.

The files where compliled correctly, but we should keep this in mind.

see discussion

We cannot have the same COMMAND_ID within one SCD bause its of the type xsd:ID. That means,we cannot define multiple primary commands like "init" with the same ID for mutliple subunits.. We should change CommandID to type xsd:string ?
Do we need the COMMAND_ID at all?

<xsd:complexType name="COMMAND_TYPE">
<xsd:sequence>
<xsd:element name="COMMAND_ID" type="xsd:ID"/>
<xsd:element name="NAME" type="xsd:string"/>
<xsd:element name="ALIAS_NAME" type="xsd:string" minOccurs="0"/>
<xsd:element name="DURATION" type="xsd:long"/>
<xsd:element name="CATEGORY" type="ECOMMAND_CATEGORY"/>
<xsd:element name="TYPE" type="ECOMMAND_TYPE"/>
<xsd:element name="DESCRIPTION" type="xsd:string" minOccurs="0"/>
<xsd:element name="FORMAL_ARGUMENTS" type="ARGUMENT_TYPE" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="EXCLUSION_LIST" type="ITEM_VALUE_TYPE" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="SYNC_RESPONSE_DATA" type="ARGUMENT_TYPE" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="PROPERTIES" type="ITEM_VALUE_TYPE" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="CONFIGURATION_COMMANDS" type="xsd:IDREF" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="REQUIRED_RESOURCES" type="xsd:IDREF" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="PRODUCED_RESCOURCES" type="xsd:IDREF" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="OUTPUT_PORTs" type="xsd:IDREF" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="INPUT_PORTs" type="xsd:IDREF" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>

see discussion

We should change the order of some items within the SCD XML schema. For example, I can only add the workbanch to the system after the location, but before domain.
We should first have the simple types and than the compelx types at the end.
This is not a real issue, it was just annoying while creating an XML file for this schema.

<xsd:complexType name="SYSTEM_TYPE">
<xsd:sequence>
<xsd:element name="NAME" type="xsd:string"/>
<xsd:element name="LOCATION" type="xsd:string"/>
<xsd:element name="WORKCELLS" type="WORKCELL_TYPE" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="RESOURCES" type="RESOURCE_TYPE" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="DOMAIN" type="ESYSTEM_DOMAIN"/>
<xsd:element name="DESCRIPTION" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>

should be

<xsd:complexType name="SYSTEM_TYPE">
<xsd:sequence>
<xsd:element name="NAME" type="xsd:string"/>
<xsd:element name="LOCATION" type="xsd:string"/>
<xsd:element name="DOMAIN" type="ESYSTEM_DOMAIN"/>
<xsd:element name="DESCRIPTION" type="xsd:string" minOccurs="0"/>
<xsd:element name="WORKCELLS" type="WORKCELL_TYPE" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element name="RESOURCES" type="RESOURCE_TYPE" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>

Proposed reordering of the SCD XML Schema.

The SCD XML Schema does not meet the current version of the w3c schema defintion.
XML-Spy updated the schema definition automatically. It did not change the "LECIS content", only the min/maxOccurs where updated.
Here are the differences from a "diff" output:

3c3
< <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
—
> <xsd:schema xmlns:xsd="http://www.w3.org/2000/10/XMLSchema">
7c7
< <xsd:element name="SYSTEM" type="SYSTEM_TYPE"/>
—
> <xsd:element name="SYSTEM" type="SYSTEM_TYPE" maxOccurs="1"/>
161c161
< <xsd:element name="SUPERCELL" type="xsd:IDREF" minOccurs="0"/>
—
> <xsd:element name="SUPERCELL" type="xsd:IDREF" minOccurs="0" maxOccurs="1"/>
293,295c293,295
< <xsd:element name="XTRANSLATION" type="xsd:long"/>
< <xsd:element name="YTRANSLATION" type="xsd:long"/>
< <xsd:element name="ZTRANSLATION" type="xsd:long"/>
—
> <xsd:element name="XTRANSLATION" type="xsd:long" maxOccurs="1" minOccurs="1"/>
> <xsd:element name="YTRANSLATION" type="xsd:long" maxOccurs="1" minOccurs="1"/>
> <xsd:element name="ZTRANSLATION" type="xsd:long" maxOccurs="1" minOccurs="1"/>
300,302c300,302
< <xsd:element name="XROTATION" type="xsd:long"/>
< <xsd:element name="YROTATION" type="xsd:long"/>
< <xsd:element name="ZROTATION" type="xsd:long"/>
—
> <xsd:element name="XROTATION" type="xsd:long" minOccurs="1" maxOccurs="1"/>
> <xsd:element name="YROTATION" type="xsd:long" maxOccurs="1" minOccurs="1"/>
> <xsd:element name="ZROTATION" type="xsd:long" maxOccurs="1" minOccurs="1"/>
330c330,331
< <xsd:element name="SYSTEM_VARIABLES" type="SYSTEM_VARIABLE_TYPE" minOccurs="0" maxOccurs="0"/>
—
> <xsd:element name="SYSTEM_VARIABLES" type="SYSTEM_VARIABLE_TYPE" minOccurs="0" maxOccurs="
> unbounded"/>
346c347,348
< <xsd:element name="SYSTEM_VARIABLES" type="SYSTEM_VARIABLE_TYPE" minOccurs="0" maxOccurs="0"/>
—
> <xsd:element name="SYSTEM_VARIABLES" type="SYSTEM_VARIABLE_TYPE" minOccurs="0" maxOccurs="
> unbounded"/>
364c366,367
< <xsd:element name="MACRO_COMMANDS" type="EXT_MACRO_COMMAND_TYPE" minOccurs="0" maxOccurs="0"/>
—
> <xsd:element name="MACRO_COMMANDS" type="EXT_MACRO_COMMAND_TYPE" minOccurs="0" maxOccurs="
> unbounded"/>

Schema amended to comply with W3C schema