[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes from TaMIE F2F Jan 13-14
Minutes from F2F Jan 13-14, attached. (minute lines starting with “o”) -jacques |
Event Description: ------------------ TaMIE F2F meeting, NIST, Gaithersburg MD. Date: Thursday / Friday , 13-14 January 2011 Host: Fujitsu US Toll Free: 877-995-3314 US Toll/International: 210-339-1806 Passcode: 9589308 Agenda: ------- Day 1 : (Thursday 9:30 AM - 5:30 PM) ----- AM: 1. Kick-off & administration matters, logistics (~15mn) - review agenda, modify if needed. 2. XTemp Specification review (A): editorial + focus on some design items (2h) - general editorial review of draft - does it read well, order of sections, examples. - review / improvement of the POST operation. - concurrency control in XTemp: only a "Virtual present (VP)-time" semantics? - event boards: read-only, read-write, write-only? - XML schema. PM: 3. XTemp Specification review (B): continuation of (A) + focus on some usage aspects: - event model: how to accommodate existing (non-TaMIE) event designs without XTemp wrappers? SAF use case. - core vs full conformance levels: where to draw the line. - is XSLT only an implementation option, or could some features surface into / extend XTemp? (e.g. XPath expressions and variables for attributes values) - review 2 example scripts in spec appendix. 4. Review of the "demo" package. - the set of "examples" (language features) and of "use cases". - review of the primer document draft (use cases intro, best practices, visibility for the XSLT implementation?). Day 2: (Friday 9:30 AM - 5:30 PM) ----- AM: 5. Using XTemp in a TestBed: - Existing Testbeds and test initiatives to consider. - testbeds and test applications from NIST / KIEC. (presentations ?) - XTemp: integration aspects, modes of use. 6. Positioning XTemp w/r to related or complementary technologies: - relationship to Event-driven techniques, CEP. - differentiation from other XML processors (XProc, XSLT, Tamelizer, Schematron) - BPM - SAF and diagnostics 6b. iMPLEMENTATION OPTIONS FOR xtEMP 7. Other Use cases, and promotion aspects: - Korean application. - BPM and monitoring (new use cases? LTS?) - B2B monitoring and choreography validation. - potential targets: GS1/RosettaNet, OAGI, GITB... - Webinar? PM: 8. Remaining issues from Day 1? (30mn max) - on the XTemp specification - on the demo package. 9. Implementation corner: - the prototype (XSLT translator), OSS status and future. - Other OSS implementations: M. Plavan, Event Driven Testing Framework - Other implementations: KorBIT - Dr CHo / Woo 10. XTemp scripting patterns, or making it easier to write scripts: - is it possible to identify a set of scripting patterns for monitoring and testing, that could lead to parameterized script templates filled using forms? 11. Next Steps: - plans for Committee specification and public review. - long term strategy: just maintenance mode or push for standard? Attendees: ---------- - Jacques Durand (Fujitsu) - Dale Moberg (Axway) - Hyunbo Cho (Pohang Univ., Korea) - Jungyub Woo, NIST - Nenad Ivezic (NIST) Action Items: ------------- AI-Jan-1: [Jacques] update specification and demo package based on comments from F2F. AI-Jan-2: [Jungyub] Identify a subset of HL7 testing use case for prototyping with XTemp. AI-Jan-3: [Jacques] To check with Chuck Morris on the best way to integrate XSLT execution with Java testbed. Minutes: ---------- Day 1 : (Thursday 9:30 AM - 5:30 PM) ----- AM: 1. Kick-off & administration matters, logistics (~15mn) - review agenda, modify if needed. o we accommodate seminar from Dale on early afternoon. o presentation from Woo on Friday morning, and more discussion on HL7 use case in he afternoon. 2. XTemp Specification review (A): editorial + focus on some design items (2h) o Detailed review of the specification. Several comments agreed on and left to editor to finalize proposals for: o Section 2: "Objectives": rewording to distinguish 3 main test objectives: Compliance with specifications, Compliance with agreements, Business activity intelligence and Operation intelligence, o Section 2.3: Focus on XML: should be a preference, not an absolute requirement. o Section 3.1: clearly distinguish the 2 top constructs (script package and scriplet) Also introduce layering of language (markup + expressions). o Several language general features from Section 2 belong now to 3.1 intro. o General rewording: concurrent invocation becomes "non-synchronized" invocation, with a semantics entirely based on handling of Virtual Present time (VP-time), as opposed to a multi-threaded senmantics (multi-thread becomes just one way to implement non-synchronized). o Some renaming in script language: @concurrent="true" --> @vptsync="false" eventbind/@postime ? eventbind/@timestampexpr o Section 3.2.1: add some explanation for RelaxNG notation. o Introduction of a start/@group attribute to identify a set of scriplet (non-synchronized) invocations that will need be joined later. o Rewording of Section 3.3 to focus extensively on synchronized vs non-synchronized invocations semantics. o Section 3.3: add figures to illustrate various cases of synchronized vs non-synchronized invocations. o Section 3.3: clarify semantics in case of a "fully past" backward synchronized invocation. o access to VP-time: by the use of a reserved variable: $currentvpt o Joining non-synchronized scriplets: may be done by extending <sleep> attributes and semantics, to "sleep" until a group of scriplets has completed execution. o Section 3.7: Exit semantics: never bubbles-up beyond a variable definition (only affects the execution inside the var def.) o Clarify/simplify examples in 3.7.1. o 3.8.1: Clarify exit semantics from inside a loop. o 3.9: Event catching: use @timestamp instad of post time. o 3.9: clarify effect of <catch> on VP-time, especially when @vptset is used. o Add catch/@vptend attribute, to define a catching window. o 3.9.4: <match> : remove @max o 3.10: Event handling: reworded section to make XTemp event structure just an option, not precluding others. Added event-board/@root and event-board/eventbind element, to acommodate other event structures. o Added 3.12.2 to mention special non-synchronized cases and impossibility to execute some scripts 100% live. o Added 3.12.3 on Joining scriplet executions. o Section 4: reworded to make XTemp event structure just an option. Defines 3 general Rules that any ad-hoc event board must follow to be processable. o Section 5 COnformance: clarify "Core" level as supporting the default XTemp event structure. o XML schemas: need updates. PM: 3. XTemp Specification review (B): continuation of (A) + focus on some usage aspects: - is XSLT only an implementation option, or could some features surface into / extend XTemp? o yes, setting attr values in X-effects is useful - should reuse same technique as for XSLT to force evaluation of expressions (use "{}") - review 2 example scripts in spec appendix. o look fine, need syntactic consistency with renaming above. 4. Review of the "demo" package. - the set of "examples" (language features) and of "use cases". o The demo package will need to take out the prototype, which should not be distributed by OASIS but by an OSS distributor (e.g. Google Code) o demo package need have a new "ad-hoc" event use case, which can be OASIS SAF (symptoms) use case. o Primer needs update to show how to process "ad-hoc" events. Day 2: (Friday 9:30 AM - 5:30 PM) ----- AM: 5. Using XTemp in a TestBed: o J.Woo presentation about HL7 compliance testbed. 6. Positioning XTemp w/r to related or complementary technologies: - relationship to Event-driven techniques, CEP. - differentiation from other XML processors (XProc, XSLT, Tamelizer, Schematron) - BPM - SAF and diagnostics o XTemp is NOT CEP, still positioned as a tsting and monitoring lge for generating reports and metrics, more than for real-time notification. o Important: a real-time notification semantics of XTemp execution, would require a careful implentation w/r to non-synchronized scriplets: in that case single-threaded impl may not be sufficient. 6b. iMPLEMENTATION OPTIONS FOR xtEMP 7. Other Use cases, and promotion aspects: - Korean application. - BPM and monitoring (new use cases? LTS?) - B2B monitoring and choreography validation. - potential targets: GS1/RosettaNet, OAGI, GITB... - Webinar? o We discussed two main options for deployment: (a) standalone XTemp execution (e.g. using XSLT translator locally) (b) integrated with a testbed as a service, to be run over logs at various frequency (e.g. every day) A fully real-time execution may be needed only if real-time notifications needed. PM: 8. Remaining issues from Day 1? (30mn max) - on the XTemp specification - on the demo package. 9. Implementation corner: - the prototype (XSLT translator), OSS status and future. - Other OSS implementations: M. Plavan, Event Driven Testing Framework - Other implementations: KorBIT - Dr CHo / Woo o Comments from M.Plavan to be examined once posted on comments list. o Prototype: updated for handling ad-hoc events, works on SAF. o Cho: important to be able to handle ad-hoc. o Prototype: currently more than just "Core conformance" level, but less than Full conformance. Will likely stay that way. o Jacques: I may upgrade it to get more complete handling of VP-time attr and variables, if time allows. May need advice from Chuck. 10. XTemp scripting patterns, or making it easier to write scripts: - is it possible to identify a set of scripting patterns for monitoring and testing, that could lead to parameterized script templates filled using forms? o Jacques & Cho: at some point, writing a library of script "templates" highly parameterized, will allow for ease of use from end-user (e.g. customization using forms, to generate executable scripts) 11. Next Steps: - plans for Committee specification and public review. - long term strategy: just maintenance mode or push for standard? o Jacques: we'll have an issue with the 3 statements of use rule: we have so far 1 implementation, maybe 2 with KorBIT/NIST. But 3rd one is from non-OASIS member. o so we'll shoot for committee specification status by this summer, then wait to see if broader adoption before moving to OASIS standard.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]