International organisation for standardisation organisation internationale de normalisation

11.3Action Points

12LASeR & SAF (14496-20)

12.1Topics

12.1.1ISO/IEC 14496-20:2008 AMD 2 Adaptation

12.1.2ISO/IEC 14496-20:2008 AMD 3 PSI

12.2Contributions

Session	Number	Title	Source
Scene	m16283	Editor's review of 14496-20 FPDAM2		Jean Le Feuvre
Scene	m16351	study text on LASeR PDAM3		Seo-Young Hwang
Scene	m16408	Responses to LASeR PDAM3 Editor’s Note		Jihun Cha Injae Lee Young-kwon Lim Han-Kyu Lee Jinwoo Hong
Scene	m16410	KNB Comment on 14496-20 PDAM3		KNB
Scene	m16350	user interaction method on 14496-20		Seo-Young Hwang Kyungmo Park Jaeyeon Song Young-Kwon Lim

M16283:

Discussion on the SDL syntax: some feedback from Expway received. It should be BiM Compatible but there is no guarantee. The BiM experts are not interested in thoroughly checking the BiM encoding.

Editor's notes:

'on specific conditions' is not defined. Proposal to change it to "up to the implementation". Accepted.

minSize on grouping elements. Accepted.

Mistakes in LASeR ML. Corrected version uploaded.

We need to produce a study and have a resolution for NB to consider the study as ballot text.

M16351:

This contribution is not a study.

Proposal of a new 'entry' attribute on the externalReference element of PSI.

Notion of "entrance node" to factorize multiple accesses to the same subtree.

Semantics need to be clarified to describe the behavior of nested externalReference elements and default behavior if not present. Need to restrict the value of the attribute to point to element.

Question whether the entry attribute should be on the 'externalReference' element or on the 'g' element? The same question applies to the update attribute also.

Attribute accepted.

Discussion on the externalReference element: choices are keep it or spread its attribute on containers.

If we keep the element, its content is not rendered by a regular SVG player. But it's not a problem, one can always use defs and use elements. Plus, in terms of processing it keeps the processing of all containers as is. And it keeps the LASeR and SVG specs separate. So, we resolve to keep the LASeR externalReference element and add the 'entry' attribute.


M16408:

Answers to the editor's note + new proposals.

Editor's Notes:

- The name PSI creates confusion with MPEG-2 PSI

Proposal to change the activity, the name of the amendment to "Presentation and Alteration of Structured Information". Comments on the 'alteration' word. The name 'Modification' is preferred to 'Alteration'. Accepted for both the activity name and the scheme (mpeg-pmsi).
- Catch internal events and not only external resources using PSI

Generalization of the resourceUpdate event. Accepted.

Comment on the difference between Structured Information and general signal (like phone call notification). We need to clarify if events like 'phone call notification' can be treated as Structured Information. If yes, the phone call notification structure should be clearly defined with a schema. The usage of PSI for events depends on the complexity of the information being carried in the event. The question is what is the threshold.

We cannot remove the externalValueEvent unless we make a corrigendum. The externalValueEvent is more efficient for events carrying a single value while the proposal is able to carry complex events. The specification should have a note indicating the difference between the two types of events.

The example in the presentation shows that the usage of the resourceUpdate event is not clear. Update of psi referenced text is automatic and can be changed using the update attribute. However, the event can be used to trigger script, navigation or animation, as usual.

We have 2 options for the event: typed event or xmlUpdateEvent with string value. One participant prefers the XML event and the others have no objection. Resolve to use the xmlUpdateEvent.

Discussion on the clarification of what happens when the PSI scheme points to a Node Set. Resolved to use the first node in the Node Set.
- Applicable media types

The problem is to define a fragment identifier scheme for all XML documents because the name of the scheme may be in conflict with the name of a scheme defined by the specification owning the media type of the XML document. However, this case is very unlikely. We will fix the problem if it arises. We could minimize this probability by calling the scheme mpeg-pmsi(). Accepted.

Proposals:

- LASeR importData element

The problem is that text in tref cannot be edited and saved because tref is a 1.1 element and the editable attribute is a 1.2 attribute. Chances that the editable attribute is added to the tref element are high. We prefer that solution. The importData element is refused but the problem is solved.
- LASeR Drag element

Defines a new element to monitor new types of events (slide, rotations) and modifies the transform attribute of the parent. The element is very similar to the animateMotion element. We could put the proposal in a TuC for a new amd on Advanced Interactions.