Issue 6064: datatype TypeID. But CORBA 3 was define keyword - typeid.
Issue 6320: clash with keyword "home" in CORBA spec
Issue 6334: DAIS::DataAccess::Item::ItemHome::find_each()
Issue 6335: DAIS::DataAccess::Item::Home::get_ids()
Issue 6336: DAIS::DataAccess::GroupEntry::Manager::create_entries()
Issue 7076: Bad parameters exception
Issue 7077: Missing description of simple_io_home
Issue 7078: Missing exception InvalidFilter
Issue 7079: find_by_type to take a node sequence
Issue 7080: ItemHome in description shall be just Home
Issue 7081: OPC_QUALITY_EGU_EXCEEDED twice in table
Issue 7082: Change user quality from short to long
Issue 7083: The SimpleIO need an own error report struct
Issue 7084: Data type for VT_EMPTY
Issue 7085: Description of validate_entries
Issue 7086: Meaning of A&E Reason
Issue 7137: Improved A&E error reporting on enable/disable by area and source
Issue 7138: A&E Keep alive supervision
Issue 6064: datatype TypeID. But CORBA 3 was define keyword - typeid. (dais-rtf)
Click here for this issue's archive.
Nature: Clarification
Severity: Critical
Summary: In this idl-file is defined datatype TypeID. But CORBA 3 was define keyword - typeid.
In result idl compiler write:
tao_idl: "DAISCommon.idl", line 15: spelling differs from IDL keyword only in case: "TypeID" tao_idl: "DAISCommon.idl", line 20: spelling differs from IDL keyword only in case: "TypeID"
Resolution: To avoid keyword collision in CORBA 3 the existing type ResourceID replaces TypeID
Revised Text: Refer to dtc/2004-10-06 with changes commented with this issue number
Actions taken:
August 24, 2003: received issue
March 10, 2005: closed issue
Issue 6320: clash with keyword "home" in CORBA spec (dais-rtf)
Click here for this issue's archive.
Nature: Clarification
Severity: Critical
Summary: Regarding the specification "IDL for Data Acquisition from Industrial Systems": The IDL files define interfaces named Home, which clash with the keyword "home" of the CORBA 3 specification.
The TAO IDL compiler reports: tao_idl: "DAISNode.idl", line 33: spelling differs from IDL keyword only in case: "Home"
Resolution: "Home" interfaces are renamed to "IHome" the distinguish from the keyword Home
Revised Text: Refer to dtc/2004-10-06 with changes commented with this issue number.
Actions taken:
October 13, 2003: received issue
March 10, 2005: closed issue
Issue 6334: DAIS::DataAccess::Item::ItemHome::find_each() (dais-rtf)
Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary: When describing what DAIS::DataAccess::Item::ItemHome::find_each() returns, the specification says:
"return: An >>iterator<< holding the item descriptions"
I suppose that word >>iterator<< should be replaced with >>sequence<< since the IDL definition is:
Descriptions find_each(in ItemIDs items) raises (UnknownItemID);
Resolution: Changed according to suggestion
Revised Text: Refer to dtc/2004-10-05 section 4.2.4.2
Actions taken:
October 17, 2003: received issue
March 10, 2005: closed issue
Issue 6335: DAIS::DataAccess::Item::Home::get_ids() (dais-rtf)
Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary: When describing DAIS::DataAccess::Item::Home::get_ids() the specification says:
"Translate a sequence of pathnames to the corresponding sequence of >>node<< identifications. If a pathname fails to translate to >>node<< identification..."
I suppose that word >>node<< should be replaced with >>item<< because: 1) the IDL definition for this method is: ItemIDs get_ids(in Strings pathnames); 2) description of return values on page 4-22 says: "return The corresponding sequence of >>item<< identifications."
Resolution: Changed according to suggestion
Revised Text: Refer to dtc/2004-10-05 section 4.2.4.2
Actions taken:
October 17, 2003: received issue
March 10, 2005: closed issue
Issue 6336: DAIS::DataAccess::GroupEntry::Manager::create_entries() (dais-rtf)
Click here for this issue's archive.
Nature: Clarification
Severity: Minor
Summary: When describing: DAIS::DataAccess::GroupEntry::Manager::create_entries() last paragraph on page 4-38 says:
"both item and pathname specified ->..."
I think that there is no way to specify both itemID and pathname in this method. Paramethers passed in this method are:
DAIS::DataAccess::GroupEntry::Description
where for item identification we use union, described on page 3-3,3-6:
DAIS::ServerItemIdentification
So, how we can specify both item ID and pathname?
Resolution: Update the text to reflect the IDL
Revised Text: Refer to dtc/2004-10-05 section 4.2.6.2.
Actions taken:
October 17, 2003: received issue
March 10, 2005: closed issue
Issue 7076: Bad parameters exception (dais-rtf)
Click here for this issue's archive.
Source: ABB Power Technologies, Power Automation & Substat (Mr. Lars-Ola Osterlund, lars-ola.g.osterlund(at)se.abb.com)
Nature: Clarification
Severity: Minor
Summary:
Bad parameters are signaled with the error code E_INVALIDARG. The corresponding OMG exception is BAD_PARAM. Remove InvalidStateSpecified in E&A Subscription and use BAD_PARAM instead
Description of simple_io_home is missing in section 4.2.2.2
Exception InvalidFilter is missing in find_by_parent() and find_by_type() in section 3.1.7.2.
find_by_type currently takes a single root node as input. By changing this to a sequence it is possible to use a set of nodes from a previous call as input to a subsequent call
Allowing multiple root Nodes as input makes the server more complex and requires the server to merge the results from each Node. It is questionable if the value to the client justifies the increased server side complexity
In description of Item::Home the interface is called ItemHome, shall be just Home
OPC_QUALITY_EGU_EXCEEDED twice in table describing detailed quality flags for uncertain quality. Remove one entry.
User quality is currently a unsigned short. This is insufficient and shall be increased to a long
The SimpleIO need an own error report struct as it can't use the handles in the ItemError struct. Suggestion
struct ItemError
{
Error err;
ServerItemIdentification id;
string reason;
};
A new datatype that corresponds to OPC VT_EMPTY is needed to indicate that the server shall use the native data type. SimpleValueType needs a UNSPECIFIED_TYPE
The DAIS specification states that validate_entries (on DAISGroupEntry) is: "Used to check if Descriptions a client holds are still valid without effecting the existing group." The OPC specification of ValidateItems (on IOPCItemMgt) states: "Determines if an item is valid (could it be added without error). Also returns information about the item such as canonical datatype. Does not affect the group in any way." Update the specification to reflect the behavior according to the OPC specification
The Alarms & Events Reason is claimed to describe the reason behind an event. Reason is mapped to OPC EventCategory. OPC EventCategory is more intended to describe the contents of an event rather than the reason causing the event. Investigate if this shall cause a name change of Reason to EventCategory. This will simplify mapping DAIS A&E to OPC A&E.
The methods enable_conditions() and disable_conditions() at the Source::Home and Area::Home does not return error codes for Sources or Areas that fails.
When an A&E subscription has a non-zero keep-alive time, the server will insure that the client receives a callback on the subscription minimally at rate indicated by the keep-alive time, even when there are no new events to report. By providing callbacks at a minimum known frequency, the client can be assured of the health of the server and subscription without resorting to "pinging the server" (the common practice of making periodic calls to a server method, e.g. IOPCEventServer::GetStatus() ).