WP3

Work package 3 contains the reference test cases for validating USDL.

Tasks

1. T3.1: Specification of reference test cases
2. T3.2: Implementation of reference test cases
3. T3.3: Evaluation of current USDL version

Deliverables

• D3.1 “Specification of reference test cases” (T3.1), due M3
  • Specification of four reference test cases
    • Service Consumer
    • Service Provider (Provisioning)
    • Service Provider (Engineering)
    • Service Host
• D3.2: “Implementation of reference test cases” (T3.2), due M4
  • Implementation of selected reference test cases
• D3.3: “Evaluation Result and remarks for USDL rework”, due M2
  • Results of the evaluation and remarks of how to rework USDL

Scenario Descriptions

Available Scenarios

• File:XG USDL WP3 2011328 UseCase Siemens.pdf
• File:XG USDL WP3 2011411-CA Use case.pdf
• File:2011-05-09 USDL XG – WP3 SAP use case.pdf
• File:XG USDL WP3 2011412 Use Case Frauenhofer IAO.pdf
• File:XG USDL WP3 2011509 HP Use Case.pdf

What makes an implementation?

I asked Coralie, what we need for proving the implementations, what their nature should be, etc. This is the answer:

• Process for PR entry says [1], "Preferably, the Working Group SHOULD be able to demonstrate two interoperable implementations of each feature."
• There is no absolute requirement that the implementations be open source, but in general I think people like to see at least one.
• There's no formal process for demonstrating independence; we just rely on people to tell us that the code bases are different.
• The nature of interop depends on the spec. (If it's a protocol, it's nice to see two ends of the protocol; if it's not, then we wouldn't expect two clients to talk to each other, for instance).