International organisation for standardisation organisation internationale de normalisation

Conf. and Ref. SW

Do we want to test conformance of bitstream (widgets) or of implementation (widget managers) or of both ?

What is currently normative in our spec:

- XML syntax for manifest extensions => proposed tool for reference software: a parser that validates the extension

- Widget Manager Behavior:

- Composition is not a normative behaviour or at least not in MPEG-U, it is a SVG, LASeR, BIFS problem. We could reuse GPAC for that.

- Life Cycle:

- Conformance of the "Processing of a Widget Package" should be done by the W3C (To be checked)

- Presentation of a widget list or widget icons is implementation specific: no conformance. We could reuse GPAC.

- Selection of a widget to activate and the state of activation (full, simple) is implementation specific: no conformance. We could reuse GPAC.

- Validation of the interfaces with the scene => proposed tool for reference software: not difficult if no script. We can probably only provide that as a reference software. We could also use GPAC to dump the scene after init (execution of load scripts …) and then validate. We could also modify the spec to mandate that either the fully scripted solution is used or all the nodes are declared in the initial scene document.

- Transition between representations is implement specific. We could use GPAC.

- Event generation and handling:

- Interface Binding: depends on the network protocols.

- communication privileges: implementation specific. We could use GPAC.

- widget communication start and termination: implementation specific. We could use GPAC.

- Widget Packaging:

- Conformance of ISO BMFF widget package => we can use the libisomedia reference software.

Note: "at the root level" should be changed to "at the file level".

- Widget API: We could have reference software in which we could change the implementation of the API and test the replacement over a test suite of files using that API.

- Predefined Services

- Aggregation: we could check that references in components/interface match.
Discussion about the licence of the reference software.

GPAC is LGPL and implements the whole spec but the licence is not compatible with ISO licence for reference software.

One option is to provide a minimal reference software which does only validation of XML.

The other option could be to use GPAC as an environment within which the reference software could run, e.g. as a module, to check API implementation, binding algorithm, communication …

In terms of sequences, we need to test all attributes. It could be one sequence with all the possible attributes. 2 sequences: one completely declarative and the other one completely scripted.