Logo etsi

ETSI's Bug Tracker

Notice: information submitted on the ETSI issue Tracker may be incorporated in ETSI publication(s) and therefore subject to the ETSI IPR policy.

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0007365Part-1 Metamodel[TDL] Technicalpublic02-02-2016 12:5108-03-2016 15:02
ReporterPhilip Makedonski 
Assigned ToPhilip Makedonski 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version[TDL] Part-1 V1.2.1 
Target Version[TDL] Part-1 V1.3.1Fixed in Version[TDL] Part-1 V1.3.1 
Summary0007365: Allow arguments for AnyValue and AnyValueOrOmit
DescriptionCurrently the "Empty 'argument' and 'reduction' sets " constraint under SpecialValueUse prohibits the use of arguments for AnyValue and AnyValueOrOmit. However, there are valid cases where AnyValue with a particular characteristic, such as partially specified StructuredDataInstance is desirable. Hence, the constraint shall be relaxed for SpecialValueUse to prohibiting the use of reduction sets. The empty argument set constraint applies only to OmitValue.

The consequence is that the semantics in such scenarios needs to be defined as well. The proposal is to treat unspecified values as <undefined>, meaning handled outside the scope of TDL in case they are used in interactions. In case more specific treatment is desired, then the user shall explicitly specify a concrete value or a SpecialValueUse for the remaining members of a structured data instance.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0013800)
Philip Makedonski (manager)
03-02-2016 09:37

The semantics shall be refined to treat unspecified values of members as AnyValue or AnyValueOrOmit in case of optional members.

In case some of the members need to be specified and AnyValue is used directly in an interaction, the data type shall be provided. In other cases the data type can be inferred, hence the arguments can be specified without the need for providing the data type.

This change has implications on the graphical syntax. A separate CR will be filled for Part 2.
(0013830)
Philip Makedonski (manager)
15-02-2016 12:45
edited on: 02-03-2016 11:47

As proposed. Unspecified members shall be treated as AnyValue and not as <unspecified>.

(0013868)
Philip Makedonski (manager)
01-03-2016 13:27

Reopened due to concerns expressed from Siemens.
(0013869)
Philip Makedonski (manager)
01-03-2016 13:27

Reverted to disallowing parameters.
(0013870)
Philip Makedonski (manager)
01-03-2016 13:28
edited on: 02-03-2016 11:47

Reverted to allowing parameters as per the original resolution.

(0013872)
Philip Makedonski (manager)
01-03-2016 16:24

Reopened for discussion during SG meeting.
(0013880)
Philip Makedonski (manager)
08-03-2016 14:57

Based on the outcome from the SG meeting discussion the feature shall be implemented as follows:

 * Keep AnyValue and AnyValueOrOmit without parameters
 * Introduce "InlineDataInstance" which shall be treated the same way as DataInstance
 * Introduce a modifier to change the interpretation of unassigned members of an existing DataInstance and InlineDataInstance setting them to AnyValue or AnyValueOrOmit
 * The modifier shall also be introduced for StructuredDataInstance definitions

On the technical level both solutions are equivalent and there is no difference in practice.
(0013881)
Philip Makedonski (manager)
08-03-2016 15:02

Resolved with
 * Keep AnyValue and AnyValueOrOmit without parameters
 * DataInstanceUse has been extended to enable the definition of "inline data specifications" where no reference to an existing DataInstance is required, instead its Members may be partially or fully specified. In case DataInstanceUse is used as the argument of an Interaction, the optional DataType property shall be specified
 * A modifier has been added to DataInstanceUse and StructuredDataInstance to enable changing the interpretation of unassigned members by setting them to AnyValue or AnyValueOrOmit

- Issue History
Date Modified Username Field Change
02-02-2016 12:51 Philip Makedonski New Issue
02-02-2016 12:51 Philip Makedonski Status new => assigned
02-02-2016 12:51 Philip Makedonski Assigned To => Philip Makedonski
03-02-2016 09:37 Philip Makedonski Note Added: 0013800
15-02-2016 12:45 Philip Makedonski Note Added: 0013830
15-02-2016 12:45 Philip Makedonski Status assigned => resolved
15-02-2016 12:45 Philip Makedonski Fixed in Version => [TDL] Part-1 V1.3.1
15-02-2016 12:45 Philip Makedonski Resolution open => fixed
01-03-2016 13:27 Philip Makedonski Note Added: 0013868
01-03-2016 13:27 Philip Makedonski Status resolved => feedback
01-03-2016 13:27 Philip Makedonski Resolution fixed => reopened
01-03-2016 13:27 Philip Makedonski Note Added: 0013869
01-03-2016 13:27 Philip Makedonski Status feedback => assigned
01-03-2016 13:28 Philip Makedonski Note Added: 0013870
01-03-2016 13:28 Philip Makedonski Status assigned => resolved
01-03-2016 13:28 Philip Makedonski Resolution reopened => fixed
01-03-2016 16:24 Philip Makedonski Note Added: 0013872
01-03-2016 16:24 Philip Makedonski Status resolved => feedback
01-03-2016 16:24 Philip Makedonski Resolution fixed => reopened
02-03-2016 11:47 Philip Makedonski Note Edited: 0013830 View Revisions
02-03-2016 11:47 Philip Makedonski Note Edited: 0013870 View Revisions
08-03-2016 14:57 Philip Makedonski Note Added: 0013880
08-03-2016 14:57 Philip Makedonski Status feedback => assigned
08-03-2016 15:02 Philip Makedonski Note Added: 0013881
08-03-2016 15:02 Philip Makedonski Status assigned => resolved
08-03-2016 15:02 Philip Makedonski Resolution reopened => fixed


MantisBT 1.2.14 [^]
Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker