Issue 5264: Imrove description of condition_logic in A&E (dais-ftf) Source: Thematix Partners LLC (Mr. Lars-Ola Osterlund, gottfried(at)telia.com) Nature: Uncategorized Issue Severity: Summary: Imrove description of condition_logic in A&E. Investigate if the currently suggested grammar can be replaced by the use of a subset from the XPath specification Resolution: see above Revised Text: Refer to comments in [1] · LOO1 in section 1.5.2 · LOO2 in new section 2.6 · LOO52 in new section 3.1.12 · LOO55 in section 4.1.4 · LOO122 in section 5.1.1 · LOO126, LOO127, LOO130, LOO132, LOO137 in section 5.2.4.2 · LOO145 in section 5.2.7.2 · LOO146 in new section 5.2.7.3 · LOO161 in section 6 Actions taken: May 2, 2002: received issue October 23, 2002: closed issue Discussion: New section 5.2.7.3 added and reference to added in 5.2.7.2. Investigate if the currently suggested grammar can be replaced by the use of a subset from the XPath specification. Add a description how to use XPath to the condition_logic and change the FilterSpec to take XPath expression. The constant const Filter FILTER_BY_SOURCE_WITH_XPATH = 0x0020; is added to tell a client if this capability is supported by a server. Filtering on Types is added to the AlarmsAndEvents::Subscription::FilterSpec to support the capability to treat source types in DAIS. The constant const Filter FILTER_BY_SOURCE_TYPE = 0x0040; is added to tell a client if this capability is supported by a server. The AlarmsAndEnvets::Subscription::FilteringIdent has the same meaning as ServerItemIdentification. Replace AlarmsAndEnvets::Subscription::FilteringIdent with ServerItemIdentification. End of Annotations:===== This is issue # 5264 Improve description of condition_logic in A&E Improve description of condition_logic in A&E. Investigate if the currently suggested grammar can be replaced by the use of a subset from the XPath specification From: "john.gillerman" To: , "Arnold deVos" , "Robert Fairchild" , "Steve Mauser" , , "Juergen Boldt" , "Linda Heaton" Cc: "Jay Britton" Subject: RE: DAIS FTF 13 Date: Thu, 23 May 2002 11:45:39 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-SLUIDL: 8F6B5CE3-45B44123-94B87E3A-9F57482C Lars, The only comment I would make is your use of TypeIDs for type filtering instead of something like SourceFilter or ReasonFilter. The limitation of TypeIDs is that they are limited to Resource ID's and consequently can not use pathnames or XPaths. Use of paths would be helpful in the case one wants to use wildcards to subscribe to all subtypes of a given class e.g. PSR/ACCE/Switch/* to subscribe to switches breakers and other children of switch. Having to navigate to each type to obtain it resource ID seems awkward to me. Given the potential complexity of the type hierarchy, I would suggest you add a struct called TypeFilter which mirrored the other filter structs. John > -----Original Message----- > From: lars-ola.osterlund@se.abb.com > [mailto:lars-ola.osterlund@se.abb.com] > Sent: Thursday, May 23, 2002 7:18 AM > To: Arnold deVos; Robert Fairchild; Steve Mauser; wavisnich@switch.com; > Juergen Boldt; Linda Heaton > Cc: Jay Britton; John Gillerman > Subject: DAIS FTF 13 > > > Hi DAIS FTF team > > After a request from John Gillerman I have made yet another update. John > wants more advanced filtering functions based on the newly > introduced XPath > as well as filtering on source types. So to meet his requirements I have > made the following changes > > 1) > DAIS already include support for types but can't filter on them. Support > for source type filtering is added by having a new TypeIDs member in the > AlarmsAndEvents::Subscription::FilterSpec. > > A new constant telling this option is available is added > const Filter FILTER_BY_SOURCE_TYPE = 0x0040; > > 2) > The AlarmsAndEvents::Subscription::FilterSpec currently contains the two > members areas and sources for filtering of sources. Both are a sequence of > FilteringIdents. FilteringIdent is a union of pathname and ResourceID. > FilteringIdent is the same as DAIS::ServerItemIdentification so it is > replaced by it. The OPC filter style for sources is supported by the new > struct > struct OPCSourceFilter { > ServerItemIdentifications areas; > ServerItemIdentifications sources; > }; > > The source filter is a new union that can hold either to OPC style or the > XPAth style filter > union SourceFilter switch(SourceFilterType) { > case OPC_SOURCE_FILTER_TYPE : OPCSourceFilter opc_source_filters; > case XPATH_SOURCE_FILTER_TYPE : string xpath_source_filter; > > }; > > A new constant telling if the XPath option is supported is added > const Filter FILTER_WITH_XPATH = 0x0020; > > 3) > The AlarmsAndEvents::Subscription::FilterSpec currently contains > the member > resons for filtering of reasons. To support XPath filtering also for > reasons a new union is added > union ReasonFilter switch(ReasonFilterType) { > case OPC_REASON_FILTER_TYPE : ServerItemIdentifications > opc_reason_filters; > case XPATH_REASON_FILTER_TYPE : string xpath_reason_filter; > }; > > 4) > ...and the new filter spec now looks like > struct FilterSpec { > ReasonFilter reason_filter; > unsigned long low_severity; > unsigned long high_severity; > SourceFilter source_filter; > TypeIDs type_filter; > }; > > 5) > As XPath filtering is not discussed in the OPC E&A spec it is made an > optional requirements such that DAIS implementations having the goal to > bridge with OPC does not need to implement XPath. > > ------------------------------------------------------------------ > > The whole thing is covered by issue 5264 and the DAISFTF report > is updated accordingly. > > (See attached file: DAISFTFrev13.ZIP) > > /Lars-Ola Subject: RE: DAIS FTF 13 Issue 5264 To: john.gillerman@sisconet.com Cc: adv@langdale.com.au, robert.fairchild@esca.com, smauser@PSYCOR.COM, wavisnich@switch.com, juergen@omg.org, jay.britton@esca.com From: lars-ola.osterlund@se.abb.com Date: Thu, 23 May 2002 18:29:04 +0200 X-MIMETrack: Serialize by Router on ABB_EMEA_SMTP02/EMEA/ABB(Release 5.0.8 |June 18, 2001) at 2002-05-23 18:32:30 Hi John The DAIS type browser doesn't support inheritance right now so I didn't took the effort to have a TypeFilter instead of the TypeID. However, I agree if we change the Type browser to support inheritance the TypeID shall be replaced by a TypeFilter in analogy with the Reason and Source filters. I think the issue of type inheritance need more investigation before we do such a change and we don't have an issue number for it. I suggest we kick off an RTF once this FTF is finnished where this is one of the issues. /Lars-Ola (Embedded "john.gillerman" image moved 2002-05-23 17:45 to file: pic27296.pcx) Lars-Ola Osterlund/SEASY/ABB@ABB_SE01 "Arnold deVos" "Robert Fairchild" "Steve Mauser" "Juergen Boldt" "Linda Heaton" "Jay Britton" Subject: RE: DAIS FTF 13 Security Level:? Internal Lars, The only comment I would make is your use of TypeIDs for type filtering instead of something like SourceFilter or ReasonFilter. The limitation of TypeIDs is that they are limited to Resource ID's and consequently can not use pathnames or XPaths. Use of paths would be helpful in the case one wants to use wildcards to subscribe to all subtypes of a given class e.g. PSR/ACCE/Switch/* to subscribe to switches breakers and other children of switch. Having to navigate to each type to obtain it resource ID seems awkward to me. Given the potential complexity of the type hierarchy, I would suggest you add a struct called TypeFilter which mirrored the other filter structs. John > -----Original Message----- > From: lars-ola.osterlund@se.abb.com > [mailto:lars-ola.osterlund@se.abb.com] > Sent: Thursday, May 23, 2002 7:18 AM > To: Arnold deVos; Robert Fairchild; Steve Mauser; wavisnich@switch.com; > Juergen Boldt; Linda Heaton > Cc: Jay Britton; John Gillerman > Subject: DAIS FTF 13 > > > Hi DAIS FTF team > > After a request from John Gillerman I have made yet another update. John > wants more advanced filtering functions based on the newly > introduced XPath > as well as filtering on source types. So to meet his requirements I have > made the following changes > > 1) > DAIS already include support for types but can't filter on them. Support > for source type filtering is added by having a new TypeIDs member in the > AlarmsAndEvents::Subscription::FilterSpec. > > A new constant telling this option is available is added > const Filter FILTER_BY_SOURCE_TYPE = 0x0040; > > 2) > The AlarmsAndEvents::Subscription::FilterSpec currently contains the two > members areas and sources for filtering of sources. Both are a sequence of > FilteringIdents. FilteringIdent is a union of pathname and ResourceID. > FilteringIdent is the same as DAIS::ServerItemIdentification so it is > replaced by it. The OPC filter style for sources is supported by the new > struct > struct OPCSourceFilter { > ServerItemIdentifications areas; > ServerItemIdentifications sources; > }; > > The source filter is a new union that can hold either to OPC style or the > XPAth style filter > union SourceFilter switch(SourceFilterType) { > case OPC_SOURCE_FILTER_TYPE : OPCSourceFilter opc_source_filters; > case XPATH_SOURCE_FILTER_TYPE : string xpath_source_filter; > > }; > > A new constant telling if the XPath option is supported is added > const Filter FILTER_WITH_XPATH = 0x0020; > > 3) > The AlarmsAndEvents::Subscription::FilterSpec currently contains > the member > resons for filtering of reasons. To support XPath filtering also for > reasons a new union is added > union ReasonFilter switch(ReasonFilterType) { > case OPC_REASON_FILTER_TYPE : ServerItemIdentifications > opc_reason_filters; > case XPATH_REASON_FILTER_TYPE : string xpath_reason_filter; > }; > > 4) > ...and the new filter spec now looks like > struct FilterSpec { > ReasonFilter reason_filter; > unsigned long low_severity; > unsigned long high_severity; > SourceFilter source_filter; > TypeIDs type_filter; > }; > > 5) > As XPath filtering is not discussed in the OPC E&A spec it is made an > optional requirements such that DAIS implementations having the goal to > bridge with OPC does not need to implement XPath. > > ------------------------------------------------------------------ > > The whole thing is covered by issue 5264 and the DAISFTF report > is updated accordingly. > > (See attached file: DAISFTFrev13.ZIP) > > /Lars-Ola pic27296.pcx