OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tamie message

[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]