Issues for LECIS Finalization Task Force

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 5472: XML Schema update
Issue 5473: XML Schema order
Issue 5474: XML Schema COMMAND_ID
Issue 5475: IDL compile problem
Issue 5476: IDL EMainCtrlState/ESTOPPED
Issue 5477: slm_event() timestamp
Issue 5478: slm_event() argument order
Issue 5479: SubUnit State Model
Issue 5480: "local_remote_req()"
Issue 5481: Typo in EResultCode
Issue 5482: InteractionID for primary commands?
Issue 5483: ELocalRemote_ArgType
Issue 5484: Control Flow
Issue 5536: Issue of aligning ASTM and OMG LECIS specifications

Issue 5472: XML Schema update (lecis-ftf)

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"/>

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> 

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>

In <xsd:complexType name="COMMAND_TYPE"> 
change 
<xsd:element name="COMMAND_ID" type="xsd:ID"/> 
to 
<xsd:element name="COMMAND_ID" type="xsd:string

 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. 

Change: Add escaped identifier for INIT and LOCAL keywords: 

On Page  7-2  change 

enum ECommandCategory { 
INIT, 
CONTROL, 
FUNCTION, 
CONFIGURE, 
RECOVERY, 
STATUSREQ, 
MAINTAIN, 
CALIBRATE, 
ADMIN, 
RESULT 
}; 

to 

enum ECommandCategory { 
_INIT, 
CONTROL, 
FUNCTION, 
CONFIGURE, 
RECOVERY, 
STATUSREQ, 
MAINTAIN, 
CALIBRATE, 
ADMIN, 
RESULT 
}; 

On page 8-2 change 

enum ELocalRemote { 
LOCAL, 
REMOTE, 
AVAILABLE 
}; 

to 

enum ELocalRemote { 
_LOCAL, 
REMOTE, 
AVAILABLE 
}; 

On Page 2-10 make the same change from LOCAL to _LOCAL  

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!! 

On page 8-1 change 

enum EMainCtrlState { 
POWERED_UP, 
INITIALIZING, 
NORMAL_OP, 
ERROR, 
CLEARING, 
CLEARED, 
SHUTDOWN, 
DOWN 
};

to 
enum EMainCtrlState { 
POWERED_UP, 
INITIALIZING, 
NORMAL_OP, 
ERROR, 
ESTOPPED, 
CLEARING, 
CLEARED, 
SHUTDOWN, 
DOWN 
};

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

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. 

Maintain the same (top-down) order in both cases (e.g., data ID, data format ID, sequence counter, data | link, etc)

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. 

Fix Figure 2-3 Word Graphic so it matches the original UML diagram which shows the correct transition.

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. 

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

SUBUNIT_UNKOWN should be SUBUNIT_UNKNOWN; 

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

We have a primary command like init, then we don't really need the 
interaction id, since there isn't any ambiguity to resolve. Nevertheless, I 
probably would leave it in the spec for implementation consistency purposes

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

enum ELocalRemote_ArgType { 
LOCAL_CTRL_REQ, 
REMOTE_CTRL_REQ, 
FORCE_LOCAL_CTRL, 
RELEASE_CONTROL 
}; 

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

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

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?

I would prefer to have the FTF complete OMG LECIS for publication and then  have a RTF or RFP address potential alignment issues. We all know that the  current version of the ASTM LECIS spec has a number of problems that need  to be worked out in a follow-up revision of the ASTM spec. Many, if not  all, of the problems with the original ASTM spec have been  addressed/resolved in the OMG spec. I think it would be easier to complete  the OMG spec for publication and then revive the ASTM working group to  update the ASTM spec by incorporating some of the solutions from the OMG  spec. Dorothe Steidinger and I have already started to look into the ASTM revision process.