Merge pull request #103 from eadrkir/master

Added and corrected template restrictions tests

conformance_test/core_language_tests/positive_tests/15_templates/1508_template_restrictions/NegSem_1508_TemplateRestrictions_037.ttcn

@@ -18,9 +18,9 @@ module NegSem_1508_TemplateRestrictions_037 {
 	type component GeneralComp {
 	}
 
-	template (omit) ExampleType m_baseTemplate(template integer MyintTemplate := ?) :={
+	template (omit) ExampleType m_baseTemplate(template (present) integer MyintTemplate := ?) :={
 		a := MyintTemplate,	
-		// template MyintTemplate contains anyvalue(?), which is not allowed in omit restriction 
+		// template (present) MyintTemplate contains anyvalue(?), which is not allowed in omit restriction 
 		b := true
 	}
 	

conformance_test/core_language_tests/positive_tests/15_templates/1508_template_restrictions/NegSem_1508_TemplateRestrictions_038.ttcn

@@ -4,7 +4,7 @@
  * Adrien Kirjak
  *
  ** @version  0.0.1
- ** @purpose  1:15.8, Ensure that template(omit) can't be parameter to template(value) if it is omit
+ ** @purpose  1:15.8, Ensure that template(present) can't be parameter to template(value) if it contains anyvalueornone(*)
  ** @verdict  pass reject
  *****************************************************************/
 
@@ -15,12 +15,11 @@ module NegSem_1508_TemplateRestrictions_038 {
 		boolean b 
     }	
 	
-	type component GeneralComp {
-	}
+	type component GeneralComp {}
 
-	template (value) ExampleType m_baseTemplate(template (omit) integer MyintTemplate := omit) :={
+	template (value) ExampleType m_baseTemplate(template (present) integer MyintTemplate := *) :={
 		a := MyintTemplate,	
-		// template (omit) MyintTemplate is omit, which is not allowed with value restriction 
+// template (present) MyintTemplate contains anyvalueornone(*), which is not allowed with value restriction 
 		b := true
 	}
 	
@@ -30,7 +29,7 @@ module NegSem_1508_TemplateRestrictions_038 {
       		setverdict(pass);
 		} else {
             setverdict(fail);
-        }
+       }
  	}
 
     control{

conformance_test/core_language_tests/positive_tests/15_templates/1508_template_restrictions/NegSem_1508_TemplateRestrictions_039.ttcn

@@ -4,7 +4,7 @@
  * Adrien Kirjak
  *
  ** @version  0.0.1
- ** @purpose  1:15.8, Ensure that template(present) can't be parameter to template(value) if it contains anyvalueornone(*)
+ ** @purpose  1:15.8, Ensure that unrestricted template can't be parameter to template(value) if it contains anyvalueornone(*)
  ** @verdict  pass reject
  *****************************************************************/
 
@@ -15,24 +15,21 @@ module NegSem_1508_TemplateRestrictions_039 {
 		boolean b 
     }	
 	
-	type component GeneralComp {
-	}
-
+	type component GeneralComp {}
 
-
-	template (value) ExampleType m_baseTemplate(template (present) integer MyintTemplate := *) :={
+	template (value) ExampleType m_baseTemplate(template integer MyintTemplate := *) :={
 		a := MyintTemplate,	
-// template (present) MyintTemplate contains anyvalueornone(*), which is not allowed with value restriction 
+	// template MyintTemplate contains anyvalueornone(*), which is not allowed with value restriction 
 		b := true
 	}
 	
 	testcase TC_NegSem_1508_TemplateRestrictions_039() runs on GeneralComp {
-
+      
 		if (ispresent(m_baseTemplate.a) == true) {
       		setverdict(pass);
 		} else {
             setverdict(fail);
-       }
+       	}
  	}
 
     control{

conformance_test/core_language_tests/positive_tests/15_templates/1508_template_restrictions/NegSem_1508_TemplateRestrictions_040.ttcn

@@ -4,7 +4,7 @@
  * Adrien Kirjak
  *
  ** @version  0.0.1
- ** @purpose  1:15.8, Ensure that unrestricted template can't be parameter to template(value) if it contains anyvalueornone(*)
+ ** @purpose  1:15.8, Ensure that template(present) can't be parameter to a template(omit)
  ** @verdict  pass reject
  *****************************************************************/
 
@@ -17,15 +17,14 @@ module NegSem_1508_TemplateRestrictions_040 {
 	
 	type component GeneralComp {}
 
-	template (value) ExampleType m_baseTemplate(template integer MyintTemplate := *) :={
-		a := MyintTemplate,	
-	// template MyintTemplate contains anyvalueornone(*), which is not allowed with value restriction 
+	template (omit) ExampleType m_baseTemplate(template (present) integer MyintTemplate := 1) :={
+		a := MyintTemplate,	// template (present)is not allowed parameter in omit restriction 
 		b := true
 	}
 	
 	testcase TC_NegSem_1508_TemplateRestrictions_040() runs on GeneralComp {
-      
-		if (ispresent(m_baseTemplate.a) == true) {
+
+		if (valueof(m_baseTemplate.b) == true) {
       		setverdict(pass);
 		} else {
             setverdict(fail);

conformance_test/core_language_tests/positive_tests/15_templates/1508_template_restrictions/NegSem_1508_TemplateRestrictions_041.ttcn

@@ -4,8 +4,8 @@
  * Adrien Kirjak
  *
  ** @version  0.0.1
- ** @purpose  1:15.8, Ensure that template (omit) can't be parameter to template(present) if it contains omit
- ** @verdict  pass reject
+ ** @purpose  1:15.8, Ensure that unrestricted template cannot be parameter to template(value)
+ ** @verdict  pass accept, ttcn3verdict:pass
  *****************************************************************/
 
 module NegSem_1508_TemplateRestrictions_041 {
@@ -18,19 +18,19 @@ module NegSem_1508_TemplateRestrictions_041 {
 	type component GeneralComp {
 	}
 
-	template (present) ExampleType m_baseTemplate(template (omit) integer MyintTemplate := omit) :={
-		a := MyintTemplate,	
-	// template (omit) MyintTemplate contains omit, which is not allowed with present restriction 
+	template (value) ExampleType m_baseTemplate(template integer MyintTemplate := 1) :={
+		a := MyintTemplate,	 // template is not allowed parameter in value restriction 
 		b := true
 	}
 	
 	testcase TC_NegSem_1508_TemplateRestrictions_041() runs on GeneralComp {
-
+      
+		
 		if (ispresent(m_baseTemplate.a) == true) {
       		setverdict(pass);
 		} else {
             setverdict(fail);
-        }
+       	}
  	}
 
     control{

conformance_test/core_language_tests/positive_tests/15_templates/1508_template_restrictions/NegSem_1508_TemplateRestrictions_042.ttcn

@@ -4,7 +4,7 @@
  * Adrien Kirjak
  *
  ** @version  0.0.1
- ** @purpose  1:15.8, Ensure that the an unrestriced template can't be parameter to template(present) if it contains omit
+ ** @purpose  1:15.8, Ensure that template(present) cannot be parameter to template(value)
  ** @verdict  pass reject
  *****************************************************************/
 
@@ -12,26 +12,26 @@ module NegSem_1508_TemplateRestrictions_042 {
 
     type record ExampleType {	// Exampletype record integer and a boolean
        	integer a,
-		boolean b 
-    }	
+	boolean b 
+       }	
 	
 	type component GeneralComp {
 	}
 
-	template (present) ExampleType m_baseTemplate(template integer MyintTemplate := omit) :={
-		a := MyintTemplate,	
-	// template MyintTemplate contains omit, which is not allowed with present restriction 
+	template (value) ExampleType m_baseTemplate(template (present) integer MyintTemplate := 2) :={
+		a := MyintTemplate,	 // template (present)is not allowed parameter in value restriction 
 		b := true
 	}
 	
 	testcase TC_NegSem_1508_TemplateRestrictions_042() runs on GeneralComp {
-
+      
+		
 		if (ispresent(m_baseTemplate.a) == true) {
       		setverdict(pass);
 		} else {
             setverdict(fail);
        }
- 	}
+ }
 
     control{
         execute(TC_NegSem_1508_TemplateRestrictions_042());

conformance_test/core_language_tests/positive_tests/15_templates/1508_template_restrictions/NegSem_1508_TemplateRestrictions_043.ttcn

+/******************************************************************************
+ * Copyright (C) 2016 ETSI  All Rights Reserved.
+ *
+ * Adrien Kirjak
+ *
+ ** @version  0.0.1
+ ** @purpose  1:15.8, Ensure that template(present) can be parameter to template(omit)
+ ** @verdict  pass reject
+ *****************************************************************/
+
+module NegSem_1508_TemplateRestrictions_043 {
+
+    type record ExampleType {	// Exampletype record integer and a boolean
+       	integer a,
+		boolean b 
+    }	
+	
+	type component GeneralComp {
+	}
+
+	template (omit) ExampleType m_baseTemplate(template integer MyintTemplate := 1) :={
+		a := MyintTemplate,	// template is not allowed parameter in omit restriction 
+		b := true
+	}
+	
+	testcase TC_NegSem_1508_TemplateRestrictions_043() runs on GeneralComp {
+      
+		
+		if (ispresent(m_baseTemplate.a) == true) {
+      		setverdict(pass);
+		} else {
+            setverdict(fail);
+       	}
+ 	}
+
+    control{
+        execute(TC_NegSem_1508_TemplateRestrictions_043());
+    }
+}

conformance_test/core_language_tests/positive_tests/15_templates/1508_template_restrictions/NegSem_1508_TemplateRestrictions_044.ttcn

+/******************************************************************************
+ * Copyright (C) 2016 ETSI  All Rights Reserved.
+ *
+ * Adrien Kirjak
+ *
+ ** @version  0.0.1
+ ** @purpose  1:15.8, Ensure that the restrictiveness of parameters template(value)->template(present) is handled correctly.
+ ** @verdict  pass reject, noexecution
+ *****************************************************************/
+
+// ATTENTION: valid for TTCN-3:2013 (ETSI ES 201 873-1 V4.5.1) and newer
+// Older versions of the core language standard didn't allow this type of 
+// modification because of restriction 15.8.c.
+
+// ATTENTION: This is not allowed in Titan
+
+/*
+Pro opinion:
+Test an intentional change made on the request of the STF160 in TTCN-3:2013. In particular, restriction 15.8.c was taken away from the core language specification (as marked in test case comments). This restriction did indeed mean that the tests would behave as you described, thus producing an error. However, with the restriction missing, the tests are perfectly valid. I also do not understand why you claim that it would not be possible to instantiate super-templates in these cases. Restrictions are always related to actual values and if the values satisfy both restrictions (parent and modified), there's no problem at all. And this is exactly what these test intend to verify.
+Besides, the core language specification does not say that the parameters must be the same. There's a rule saying that the parameters shall not be omitted. It is rather unfortunate wording, because it might be interpreted in several ways. There's a CR 6692 regarding this issue.
+
+Contra opinion
+The problem is with the semantics of modified templates. For every actual parameter list, first, the template-to-be-modified is implicitly instantiated and then modified by the given modifications. If the template-to-be-modified is not defined for the actual parameters, then neither is the modified one. Of course, you are right in that this restriction could be applied for actual parameters only and need not be checked at the template-level already. However, it does not make sense to lessen the template restriction of a parameter, as implicitly, it still keeps the stronger restriction (because of the modification-semantics). Therefore, it is misleading to SEEMINGLY allow a template(present) parameter for a template where the super-template has a template(value) parameter. If allowed, the user might use a non-value template as an actual parameter and then get a runtime error, even though the template-restriction matched the one in the formal parameter of the template. Therefore, we interpret the standard in such a way that the inheritance of the parameters includes the inheritance of both the types and the template restrictions of the inherited parameters. Strengthening of template restrictions would indeed not be a problem. Lessening is.
+
+*/
+
+module NegSem_1508_TemplateRestrictions_044 {
+
+	type component GeneralComp { }
+
+    type record ExampleType {
+        integer a,
+        boolean b optional
+    }
+
+    template(present) ExampleType m_baseTemplate(template(value) integer p_myInt) := {
+        a := p_myInt,
+        b := true
+    }
+	
+    template(present) ExampleType m_modifiedTemplate(template(present) integer p_myInt) modifies m_baseTemplate := { // value -> present restriction change is not allowed
+        a := 21
+    }
+
+	testcase TC_NegSem_1508_TemplateRestrictions_044() runs on GeneralComp {
+        if (match(valueof(m_modifiedTemplate(1).a), 21) and
+            match(valueof(m_modifiedTemplate(1).b), true)
+        ) {
+            setverdict(pass);
+        } else {
+            setverdict(fail);
+        }
+    }
+
+    control{
+        execute(TC_NegSem_1508_TemplateRestrictions_044());
+    }
+}

conformance_test/core_language_tests/positive_tests/15_templates/1508_template_restrictions/NegSem_1508_TemplateRestrictions_045.ttcn

+/******************************************************************************
+ * Copyright (C) 2016 ETSI  All Rights Reserved.
+ *
+ * Adrien Kirjak
+ *
+ ** @version  0.0.1
+ ** @purpose  1:15.8, Ensure that the restrictiveness of parameters template(value)->template(omit) is handled correctly.
+ ** @verdict  pass accept, ttcn3verdict:pass
+ *****************************************************************/
+
+// ATTENTION: valid for TTCN-3:2013 (ETSI ES 201 873-1 V4.5.1) and newer
+// Older versions of the core languate standard didn't allow this type of 
+// modification because of restriction 15.8.c.
+
+// ATTENTION: This is not allowed in Titan
+
+/*
+Pro opinion:
+Test an intentional change made on the request of the STF160 in TTCN-3:2013. In particular, restriction 15.8.c was taken away from the core language specification (as marked in test case comments). This restriction did indeed mean that the tests would behave as you described, thus producing an error. However, with the restriction missing, the tests are perfectly valid. I also do not understand why you claim that it would not be possible to instantiate super-templates in these cases. Restrictions are always related to actual values and if the values satisfy both restrictions (parent and modified), there's no problem at all. And this is exactly what these test intend to verify.
+Besides, the core language specification does not say that the parameters must be the same. There's a rule saying that the parameters shall not be omitted. It is rather unfortunate wording, because it might be interpreted in several ways. There's a CR 6692 regarding this issue.
+
+Contra opinion
+The problem is with the semantics of modified templates. For every actual parameter list, first, the template-to-be-modified is implicitly instantiated and then modified by the given modifications. If the template-to-be-modified is not defined for the actual parameters, then neither is the modified one. Of course, you are right in that this restriction could be applied for actual parameters only and need not be checked at the template-level already. However, it does not make sense to lessen the template restriction of a parameter, as implicitly, it still keeps the stronger restriction (because of the modification-semantics). Therefore, it is misleading to SEEMINGLY allow a template(present) parameter for a template where the super-template has a template(value) parameter. If allowed, the user might use a non-value template as an actual parameter and then get a runtime error, even though the template-restriction matched the one in the formal parameter of the template. Therefore, we interpret the standard in such a way that the inheritance of the parameters includes the inheritance of both the types and the template restrictions of the inherited parameters. Strengthening of template restrictions would indeed not be a problem. Lessening is.
+
+*/
+
+module NegSem_1508_TemplateRestrictions_045 {
+
+	type component GeneralComp { }
+
+    type record ExampleType {
+        integer a,
+        boolean b optional
+    }
+
+    template(present) ExampleType m_baseTemplate(template(value) integer p_myInt) := {
+        a := p_myInt,
+        b := true
+    }
+
+    template(present) ExampleType m_modifiedTemplate(template(omit) integer p_myInt) modifies m_baseTemplate := { // value -> omit restriction change is not allowed
+        a := 21
+    }
+	
+	testcase TC_NegSem_1508_TemplateRestrictions_045() runs on GeneralComp {
+        if (match(valueof(m_modifiedTemplate(1).a), 21) and
+            match(valueof(m_modifiedTemplate(1).b), true)
+        ) {
+            setverdict(pass);
+        } else {
+            setverdict(fail);
+        }
+    }
+
+    control{
+        execute(TC_NegSem_1508_TemplateRestrictions_045());
+    }
+
+}

conformance_test/core_language_tests/positive_tests/15_templates/1508_template_restrictions/NegSem_1508_TemplateRestrictions_046.ttcn

+/******************************************************************************
+ * Copyright (C) 2016 ETSI  All Rights Reserved.
+ *
+ * Adrien Kirjak
+ *
+ ** @version  0.0.1
+ ** @purpose  1:15.8, Ensure that the restrictiveness of parameters template(value)->template is handled correctly.
+ ** @verdict  pass accept, ttcn3verdict:pass
+ *****************************************************************/
+
+// ATTENTION: valid for TTCN-3:2013 (ETSI ES 201 873-1 V4.5.1) and newer
+// Older versions of the core languate standard didn't allow this type of 
+// modification because of restriction 15.8.c.
+
+// ATTENTION: This is not allowed in Titan
+
+/*
+Pro opinion:
+Test an intentional change made on the request of the STF160 in TTCN-3:2013. In particular, restriction 15.8.c was taken away from the core language specification (as marked in test case comments). This restriction did indeed mean that the tests would behave as you described, thus producing an error. However, with the restriction missing, the tests are perfectly valid. I also do not understand why you claim that it would not be possible to instantiate super-templates in these cases. Restrictions are always related to actual values and if the values satisfy both restrictions (parent and modified), there's no problem at all. And this is exactly what these test intend to verify.
+Besides, the core language specification does not say that the parameters must be the same. There's a rule saying that the parameters shall not be omitted. It is rather unfortunate wording, because it might be interpreted in several ways. There's a CR 6692 regarding this issue.
+
+Contra opinion
+The problem is with the semantics of modified templates. For every actual parameter list, first, the template-to-be-modified is implicitly instantiated and then modified by the given modifications. If the template-to-be-modified is not defined for the actual parameters, then neither is the modified one. Of course, you are right in that this restriction could be applied for actual parameters only and need not be checked at the template-level already. However, it does not make sense to lessen the template restriction of a parameter, as implicitly, it still keeps the stronger restriction (because of the modification-semantics). Therefore, it is misleading to SEEMINGLY allow a template(present) parameter for a template where the super-template has a template(value) parameter. If allowed, the user might use a non-value template as an actual parameter and then get a runtime error, even though the template-restriction matched the one in the formal parameter of the template. Therefore, we interpret the standard in such a way that the inheritance of the parameters includes the inheritance of both the types and the template restrictions of the inherited parameters. Strengthening of template restrictions would indeed not be a problem. Lessening is.
+
+*/
+
+module NegSem_1508_TemplateRestrictions_046 {
+
+	type component GeneralComp { }
+
+    type record ExampleType {
+        integer a,
+        boolean b optional
+    }
+
+    template(present) ExampleType m_baseTemplate(template(value) integer p_myInt) := {
+        a := p_myInt,
+        b := true
+    }
+
+    template(present) ExampleType m_modifiedTemplate(template integer p_myInt) modifies m_baseTemplate := {
+		// value -> unrestricted change is not allowed
+        a := 21
+    }
+
+	testcase TC_NegSem_1508_TemplateRestrictions_046() runs on GeneralComp {
+        if (match(valueof(m_modifiedTemplate(1).a), 21) and
+            match(valueof(m_modifiedTemplate(1).b), true)
+        ) {
+            setverdict(pass);
+        } else {
+            setverdict(fail);
+        }
+    }
+
+    control{
+        execute(TC_NegSem_1508_TemplateRestrictions_046());
+    }
+}

conformance_test/core_language_tests/positive_tests/15_templates/1508_template_restrictions/NegSem_1508_TemplateRestrictions_047.ttcn

+/******************************************************************************
+ * Copyright (C) 2016 ETSI  All Rights Reserved.
+ *
+ * Adrien Kirjak
+ *
+ ** @version  0.0.1
+ ** @purpose  1:15.8, Ensure that the restrictiveness of parameters template(omit)->template(present) is handled correctly.
+ ** @verdict  pass accept, ttcn3verdict:pass
+ *****************************************************************/
+
+// ATTENTION: valid for TTCN-3:2013 (ETSI ES 201 873-1 V4.5.1) and newer
+// Older versions of the core languate standard didn't allow this type of 
+// modification because of restriction 15.8.c.
+
+// ATTENTION: This is not allowed in Titan
+
+/*
+Pro opinion:
+Test an intentional change made on the request of the STF160 in TTCN-3:2013. In particular, restriction 15.8.c was taken away from the core language specification (as marked in test case comments). This restriction did indeed mean that the tests would behave as you described, thus producing an error. However, with the restriction missing, the tests are perfectly valid. I also do not understand why you claim that it would not be possible to instantiate super-templates in these cases. Restrictions are always related to actual values and if the values satisfy both restrictions (parent and modified), there's no problem at all. And this is exactly what these test intend to verify.
+Besides, the core language specification does not say that the parameters must be the same. There's a rule saying that the parameters shall not be omitted. It is rather unfortunate wording, because it might be interpreted in several ways. There's a CR 6692 regarding this issue.
+
+Contra opinion
+The problem is with the semantics of modified templates. For every actual parameter list, first, the template-to-be-modified is implicitly instantiated and then modified by the given modifications. If the template-to-be-modified is not defined for the actual parameters, then neither is the modified one. Of course, you are right in that this restriction could be applied for actual parameters only and need not be checked at the template-level already. However, it does not make sense to lessen the template restriction of a parameter, as implicitly, it still keeps the stronger restriction (because of the modification-semantics). Therefore, it is misleading to SEEMINGLY allow a template(present) parameter for a template where the super-template has a template(value) parameter. If allowed, the user might use a non-value template as an actual parameter and then get a runtime error, even though the template-restriction matched the one in the formal parameter of the template. Therefore, we interpret the standard in such a way that the inheritance of the parameters includes the inheritance of both the types and the template restrictions of the inherited parameters. Strengthening of template restrictions would indeed not be a problem. Lessening is.
+
+*/
+
+module NegSem_1508_TemplateRestrictions_047 {
+
+	type component GeneralComp { }
+
+    type record ExampleType {
+        integer a,
+        boolean b optional
+    }
+
+    template(present) ExampleType m_baseTemplate(template(omit) integer p_myInt) := {
+        a := p_myInt,
+        b := true
+    }
+
+    template(present) ExampleType m_modifiedTemplate(template(present) integer p_myInt) modifies m_baseTemplate := { // omit -> present restriction change is not allowed
+        a := 21
+    }
+
+	testcase TC_NegSem_1508_TemplateRestrictions_047() runs on GeneralComp {
+        if (match(valueof(m_modifiedTemplate(1).a), 21) and
+            match(valueof(m_modifiedTemplate(1).b), true)
+        ) {
+            setverdict(pass);
+        } else {
+            setverdict(fail);
+        }
+    }
+
+    control{
+        execute(TC_NegSem_1508_TemplateRestrictions_047());
+    }
+}

conformance_test/core_language_tests/positive_tests/15_templates/1508_template_restrictions/NegSem_1508_TemplateRestrictions_048.ttcn

+/******************************************************************************
+ * Copyright (C) 2016 ETSI  All Rights Reserved.
+ *
+ * Adrien Kirjak
+ *
+ ** @version  0.0.1
+ ** @purpose  1:15.8, Ensure that the restrictiveness of parameters template(omit)->template(present) is handled correctly.
+ ** @verdict  pass accept, ttcn3verdict:pass
+ *****************************************************************/
+
+// ATTENTION: valid for TTCN-3:2013 (ETSI ES 201 873-1 V4.5.1) and newer
+// Older versions of the core languate standard didn't allow this type of 
+// modification because of restriction 15.8.c.
+
+// ATTENTION: This is not allowed in Titan
+
+/*
+Pro opinion:
+Test an intentional change made on the request of the STF160 in TTCN-3:2013. In particular, restriction 15.8.c was taken away from the core language specification (as marked in test case comments). This restriction did indeed mean that the tests would behave as you described, thus producing an error. However, with the restriction missing, the tests are perfectly valid. I also do not understand why you claim that it would not be possible to instantiate super-templates in these cases. Restrictions are always related to actual values and if the values satisfy both restrictions (parent and modified), there's no problem at all. And this is exactly what these test intend to verify.
+Besides, the core language specification does not say that the parameters must be the same. There's a rule saying that the parameters shall not be omitted. It is rather unfortunate wording, because it might be interpreted in several ways. There's a CR 6692 regarding this issue.
+
+Contra opinion
+The problem is with the semantics of modified templates. For every actual parameter list, first, the template-to-be-modified is implicitly instantiated and then modified by the given modifications. If the template-to-be-modified is not defined for the actual parameters, then neither is the modified one. Of course, you are right in that this restriction could be applied for actual parameters only and need not be checked at the template-level already. However, it does not make sense to lessen the template restriction of a parameter, as implicitly, it still keeps the stronger restriction (because of the modification-semantics). Therefore, it is misleading to SEEMINGLY allow a template(present) parameter for a template where the super-template has a template(value) parameter. If allowed, the user might use a non-value template as an actual parameter and then get a runtime error, even though the template-restriction matched the one in the formal parameter of the template. Therefore, we interpret the standard in such a way that the inheritance of the parameters includes the inheritance of both the types and the template restrictions of the inherited parameters. Strengthening of template restrictions would indeed not be a problem. Lessening is.
+
+*/
+
+module NegSem_1508_TemplateRestrictions_048 {
+
+	type component GeneralComp { }
+
+    type record ExampleType {
+        integer a,
+        boolean b optional
+    }
+
+    template(present) ExampleType m_baseTemplate(template(omit) integer p_myInt) := {
+        a := p_myInt,
+        b := true
+    }
+
+    template(present) ExampleType m_modifiedTemplate(template integer p_myInt) modifies m_baseTemplate := {
+		// omit -> unrestricted change is not allowed
+        a := 21
+    }
+
+	testcase TC_NegSem_1508_TemplateRestrictions_048() runs on GeneralComp {
+        if (match(valueof(m_modifiedTemplate(1).a), 21) and
+            match(valueof(m_modifiedTemplate(1).b), true)
+        ) {
+            setverdict(pass);
+        } else {
+            setverdict(fail);
+        }
+    }
+
+    control{
+        execute(TC_NegSem_1508_TemplateRestrictions_048());
+    }
+}

conformance_test/core_language_tests/positive_tests/15_templates/1508_template_restrictions/NegSem_1508_TemplateRestrictions_049.ttcn

@@ -4,32 +4,54 @@
  * Adrien Kirjak
  *
  ** @version  0.0.1
- ** @purpose  1:15.8, Ensure that template(present) can't be parameter to a template(omit)
- ** @verdict  pass reject
+ ** @purpose  1:15.8, Ensure that the restrictiveness of parameters template(omit)->template(present) is handled correctly.
+ ** @verdict  pass accept, ttcn3verdict:pass
  *****************************************************************/
 
+// ATTENTION: valid for TTCN-3:2013 (ETSI ES 201 873-1 V4.5.1) and newer
+// Older versions of the core languate standard didn't allow this type of 
+// modification because of restriction 15.8.c.
+
+// ATTENTION: This is not allowed in Titan
+
+/*
+Pro opinion:
+Test an intentional change made on the request of the STF160 in TTCN-3:2013. In particular, restriction 15.8.c was taken away from the core language specification (as marked in test case comments). This restriction did indeed mean that the tests would behave as you described, thus producing an error. However, with the restriction missing, the tests are perfectly valid. I also do not understand why you claim that it would not be possible to instantiate super-templates in these cases. Restrictions are always related to actual values and if the values satisfy both restrictions (parent and modified), there's no problem at all. And this is exactly what these test intend to verify.
+Besides, the core language specification does not say that the parameters must be the same. There's a rule saying that the parameters shall not be omitted. It is rather unfortunate wording, because it might be interpreted in several ways. There's a CR 6692 regarding this issue.
+
+Contra opinion
+The problem is with the semantics of modified templates. For every actual parameter list, first, the template-to-be-modified is implicitly instantiated and then modified by the given modifications. If the template-to-be-modified is not defined for the actual parameters, then neither is the modified one. Of course, you are right in that this restriction could be applied for actual parameters only and need not be checked at the template-level already. However, it does not make sense to lessen the template restriction of a parameter, as implicitly, it still keeps the stronger restriction (because of the modification-semantics). Therefore, it is misleading to SEEMINGLY allow a template(present) parameter for a template where the super-template has a template(value) parameter. If allowed, the user might use a non-value template as an actual parameter and then get a runtime error, even though the template-restriction matched the one in the formal parameter of the template. Therefore, we interpret the standard in such a way that the inheritance of the parameters includes the inheritance of both the types and the template restrictions of the inherited parameters. Strengthening of template restrictions would indeed not be a problem. Lessening is.
+
+*/
+
 module NegSem_1508_TemplateRestrictions_049 {
 
-    type record ExampleType {	// Exampletype record integer and a boolean
-       	integer a,
-		boolean b 
-    }	
-	
-	type component GeneralComp {}
-
-	template (omit) ExampleType m_baseTemplate(template (present) integer MyintTemplate := 1) :={
-		a := MyintTemplate,	// template (present)is not allowed parameter in omit restriction 
-		b := true
-	}
-	
-	testcase TC_NegSem_1508_TemplateRestrictions_049() runs on GeneralComp {
+	type component GeneralComp { }
+
+    type record ExampleType {
+        integer a,
+        boolean b optional
+    }
+
+    template(present) ExampleType m_baseTemplate(template(present) integer p_myInt) := {
+        a := p_myInt,
+        b := true
+    }
 
-		if (valueof(m_baseTemplate.b) == true) {
-      		setverdict(pass);
-		} else {
+    template(present) ExampleType m_modifiedTemplate(template integer p_myInt) modifies m_baseTemplate := {
+		// present -> unrestricted change is not allowed
+        a := 21
+    }
+
+	testcase TC_NegSem_1508_TemplateRestrictions_049() runs on GeneralComp {
+        if (match(valueof(m_modifiedTemplate(1).a), 21) and
+            match(valueof(m_modifiedTemplate(1).b), true)
+        ) {
+            setverdict(pass);
+        } else {
             setverdict(fail);
-       	}
- 	}
+        }
+    }
 
     control{
         execute(TC_NegSem_1508_TemplateRestrictions_049());

conformance_test/core_language_tests/positive_tests/15_templates/1508_template_restrictions/Sem_1508_TemplateRestrictions_031.ttcn

@@ -4,51 +4,33 @@
  * Adrien Kirjak
  *
  ** @version  0.0.1
- ** @purpose  1:15.8, Ensure that the restrictiveness of parameters template(value)->template(present) is handled correctly.
- ** @verdict  pass accept, ttcn3verdict:pass
+ ** @purpose  1:15.8, Ensure that template (omit) can be parameter to template(present) if it contains omit
+ ** @verdict  pass reject
  *****************************************************************/
 
-// ATTENTION: valid for TTCN-3:2013 (ETSI ES 201 873-1 V4.5.1) and newer
-// Older versions of the core language standard didn't allow this type of 
-// modification because of restriction 15.8.c.
-
-/*
-Pro opinion:
-Test an intentional change made on the request of the STF160 in TTCN-3:2013. In particular, restriction 15.8.c was taken away from the core language specification (as marked in test case comments). This restriction did indeed mean that the tests would behave as you described, thus producing an error. However, with the restriction missing, the tests are perfectly valid. I also do not understand why you claim that it would not be possible to instantiate super-templates in these cases. Restrictions are always related to actual values and if the values satisfy both restrictions (parent and modified), there's no problem at all. And this is exactly what these test intend to verify.
-Besides, the core language specification does not say that the parameters must be the same. There's a rule saying that the parameters shall not be omitted. It is rather unfortunate wording, because it might be interpreted in several ways. There's a CR 6692 regarding this issue.
-
-Contra opinion
-The problem is with the semantics of modified templates. For every actual parameter list, first, the template-to-be-modified is implicitly instantiated and then modified by the given modifications. If the template-to-be-modified is not defined for the actual parameters, then neither is the modified one. Of course, you are right in that this restriction could be applied for actual parameters only and need not be checked at the template-level already. However, it does not make sense to lessen the template restriction of a parameter, as implicitly, it still keeps the stronger restriction (because of the modification-semantics). Therefore, it is misleading to SEEMINGLY allow a template(present) parameter for a template where the super-template has a template(value) parameter. If allowed, the user might use a non-value template as an actual parameter and then get a runtime error, even though the template-restriction matched the one in the formal parameter of the template. Therefore, we interpret the standard in such a way that the inheritance of the parameters includes the inheritance of both the types and the template restrictions of the inherited parameters. Strengthening of template restrictions would indeed not be a problem. Lessening is.
-
-*/
-
 module Sem_1508_TemplateRestrictions_031 {
 
-	type component GeneralComp { }
-
-    type record ExampleType {
-        integer a,
-        boolean b optional
-    }
-
-    template(present) ExampleType m_baseTemplate(template(value) integer p_myInt) := {
-        a := p_myInt,
-        b := true
-    }
+    type record ExampleType {	// Exampletype record integer and a boolean
+       	integer a optional,
+		boolean b 
+    }	
 	
-    template(present) ExampleType m_modifiedTemplate(template(present) integer p_myInt) modifies m_baseTemplate := {
-        a := 21
-    }
+	type component GeneralComp {
+	}
 
+	template (present) ExampleType m_baseTemplate(template (omit) integer MyintTemplate := omit) :={
+		a := MyintTemplate,	 
+		b := true
+	}
+	
 	testcase TC_Sem_1508_TemplateRestrictions_031() runs on GeneralComp {
-        if (match(valueof(m_modifiedTemplate(1).a), 21) and
-            match(valueof(m_modifiedTemplate(1).b), true)
-        ) {
-            setverdict(pass);
-        } else {
-            setverdict(fail);
+
+		if (match(valueof(m_baseTemplate),ExampleType:{omit,true}) == true) {
+      		setverdict(pass);
+		} else {
+            setverdict(fail,m_baseTemplate);
         }
-    }
+ 	}
 
     control{
         execute(TC_Sem_1508_TemplateRestrictions_031());

conformance_test/core_language_tests/positive_tests/15_templates/1508_template_restrictions/Sem_1508_TemplateRestrictions_032.ttcn

@@ -4,54 +4,35 @@
  * Adrien Kirjak
  *
  ** @version  0.0.1
- ** @purpose  1:15.8, Ensure that the restrictiveness of parameters template(value)->template(omit) is handled correctly.
- ** @verdict  pass accept, ttcn3verdict:pass
+ ** @purpose  1:15.8, Ensure that the an unrestriced template can be parameter to template(present) if it contains omit
+ ** @verdict  pass reject
  *****************************************************************/
 
-// ATTENTION: valid for TTCN-3:2013 (ETSI ES 201 873-1 V4.5.1) and newer
-// Older versions of the core languate standard didn't allow this type of 
-// modification because of restriction 15.8.c.
-
-/*
-Pro opinion:
-Test an intentional change made on the request of the STF160 in TTCN-3:2013. In particular, restriction 15.8.c was taken away from the core language specification (as marked in test case comments). This restriction did indeed mean that the tests would behave as you described, thus producing an error. However, with the restriction missing, the tests are perfectly valid. I also do not understand why you claim that it would not be possible to instantiate super-templates in these cases. Restrictions are always related to actual values and if the values satisfy both restrictions (parent and modified), there's no problem at all. And this is exactly what these test intend to verify.
-Besides, the core language specification does not say that the parameters must be the same. There's a rule saying that the parameters shall not be omitted. It is rather unfortunate wording, because it might be interpreted in several ways. There's a CR 6692 regarding this issue.
-
-Contra opinion
-The problem is with the semantics of modified templates. For every actual parameter list, first, the template-to-be-modified is implicitly instantiated and then modified by the given modifications. If the template-to-be-modified is not defined for the actual parameters, then neither is the modified one. Of course, you are right in that this restriction could be applied for actual parameters only and need not be checked at the template-level already. However, it does not make sense to lessen the template restriction of a parameter, as implicitly, it still keeps the stronger restriction (because of the modification-semantics). Therefore, it is misleading to SEEMINGLY allow a template(present) parameter for a template where the super-template has a template(value) parameter. If allowed, the user might use a non-value template as an actual parameter and then get a runtime error, even though the template-restriction matched the one in the formal parameter of the template. Therefore, we interpret the standard in such a way that the inheritance of the parameters includes the inheritance of both the types and the template restrictions of the inherited parameters. Strengthening of template restrictions would indeed not be a problem. Lessening is.
-
-*/
-
 module Sem_1508_TemplateRestrictions_032 {
 
-	type component GeneralComp { }
-
-    type record ExampleType {
-        integer a,
-        boolean b optional
-    }
-
-    template(present) ExampleType m_baseTemplate(template(value) integer p_myInt) := {
-        a := p_myInt,
-        b := true
-    }
+    type record ExampleType {	// Exampletype record integer and a boolean
+       	integer a optional,
+		boolean b 
+    }	
+	
+	type component GeneralComp {
+	}
 
-    template(present) ExampleType m_modifiedTemplate(template(omit) integer p_myInt) modifies m_baseTemplate := {
-        a := 21
-    }
+	template (present) ExampleType m_baseTemplate(template integer MyintTemplate := omit) :={
+		a := MyintTemplate,	 
+		b := true
+	}
 	
 	testcase TC_Sem_1508_TemplateRestrictions_032() runs on GeneralComp {
-        if (match(valueof(m_modifiedTemplate(1).a), 21) and
-            match(valueof(m_modifiedTemplate(1).b), true)
-        ) {
-            setverdict(pass);
-        } else {
+
+		if (match(valueof(m_baseTemplate),ExampleType:{omit,true}) == true) {
+      		setverdict(pass);
+		} else {
             setverdict(fail);
-        }
-    }
+       }
+ 	}
 
     control{
         execute(TC_Sem_1508_TemplateRestrictions_032());
     }
-
-}
\ No newline at end of file
+}

conformance_test/core_language_tests/positive_tests/15_templates/1508_template_restrictions/Sem_1508_TemplateRestrictions_033.ttcn

@@ -4,53 +4,36 @@
  * Adrien Kirjak
  *
  ** @version  0.0.1
- ** @purpose  1:15.8, Ensure that the restrictiveness of parameters template(value)->template is handled correctly.
+ ** @purpose  1:15.8, Ensure that the an unrestriced template can be parameter to template(present)
  ** @verdict  pass accept, ttcn3verdict:pass
  *****************************************************************/
 
-// ATTENTION: valid for TTCN-3:2013 (ETSI ES 201 873-1 V4.5.1) and newer
-// Older versions of the core languate standard didn't allow this type of 
-// modification because of restriction 15.8.c.
-
-/*
-Pro opinion:
-Test an intentional change made on the request of the STF160 in TTCN-3:2013. In particular, restriction 15.8.c was taken away from the core language specification (as marked in test case comments). This restriction did indeed mean that the tests would behave as you described, thus producing an error. However, with the restriction missing, the tests are perfectly valid. I also do not understand why you claim that it would not be possible to instantiate super-templates in these cases. Restrictions are always related to actual values and if the values satisfy both restrictions (parent and modified), there's no problem at all. And this is exactly what these test intend to verify.
-Besides, the core language specification does not say that the parameters must be the same. There's a rule saying that the parameters shall not be omitted. It is rather unfortunate wording, because it might be interpreted in several ways. There's a CR 6692 regarding this issue.
-
-Contra opinion
-The problem is with the semantics of modified templates. For every actual parameter list, first, the template-to-be-modified is implicitly instantiated and then modified by the given modifications. If the template-to-be-modified is not defined for the actual parameters, then neither is the modified one. Of course, you are right in that this restriction could be applied for actual parameters only and need not be checked at the template-level already. However, it does not make sense to lessen the template restriction of a parameter, as implicitly, it still keeps the stronger restriction (because of the modification-semantics). Therefore, it is misleading to SEEMINGLY allow a template(present) parameter for a template where the super-template has a template(value) parameter. If allowed, the user might use a non-value template as an actual parameter and then get a runtime error, even though the template-restriction matched the one in the formal parameter of the template. Therefore, we interpret the standard in such a way that the inheritance of the parameters includes the inheritance of both the types and the template restrictions of the inherited parameters. Strengthening of template restrictions would indeed not be a problem. Lessening is.
-
-*/
-
 module Sem_1508_TemplateRestrictions_033 {
 
-	type component GeneralComp { }
-
-    type record ExampleType {
-        integer a,
-        boolean b optional
-    }
-
-    template(present) ExampleType m_baseTemplate(template(value) integer p_myInt) := {
-        a := p_myInt,
-        b := true
-    }
-
-    template(present) ExampleType m_modifiedTemplate(template integer p_myInt) modifies m_baseTemplate := {
-        a := 21
-    }
-
+    type record ExampleType {	// Exampletype record integer and a boolean
+       	integer a,
+		boolean b 
+    }	
+	
+	type component GeneralComp {
+	}
+
+	template (present) ExampleType m_baseTemplate(template integer MyintTemplate := 21) :={
+		a := MyintTemplate,	 
+		b := true
+	}
+	
 	testcase TC_Sem_1508_TemplateRestrictions_033() runs on GeneralComp {
-        if (match(valueof(m_modifiedTemplate(1).a), 21) and
-            match(valueof(m_modifiedTemplate(1).b), true)
-        ) {
-            setverdict(pass);
-        } else {
+      
+		
+		if (ispresent(m_baseTemplate.a) == true) {
+      		setverdict(pass);
+		} else {
             setverdict(fail);
-        }
-    }
+       	}
+ 	}
 
     control{
         execute(TC_Sem_1508_TemplateRestrictions_033());
     }
-}
\ No newline at end of file
+}

conformance_test/core_language_tests/positive_tests/15_templates/1508_template_restrictions/Sem_1508_TemplateRestrictions_034.ttcn

@@ -4,53 +4,36 @@
  * Adrien Kirjak
  *
  ** @version  0.0.1
- ** @purpose  1:15.8, Ensure that the restrictiveness of parameters template(omit)->template(present) is handled correctly.
+ ** @purpose  1:15.8, Ensure that template (omit) can be parameter to template(present)
  ** @verdict  pass accept, ttcn3verdict:pass
  *****************************************************************/
 
-// ATTENTION: valid for TTCN-3:2013 (ETSI ES 201 873-1 V4.5.1) and newer
-// Older versions of the core languate standard didn't allow this type of 
-// modification because of restriction 15.8.c.
-
-/*
-Pro opinion:
-Test an intentional change made on the request of the STF160 in TTCN-3:2013. In particular, restriction 15.8.c was taken away from the core language specification (as marked in test case comments). This restriction did indeed mean that the tests would behave as you described, thus producing an error. However, with the restriction missing, the tests are perfectly valid. I also do not understand why you claim that it would not be possible to instantiate super-templates in these cases. Restrictions are always related to actual values and if the values satisfy both restrictions (parent and modified), there's no problem at all. And this is exactly what these test intend to verify.
-Besides, the core language specification does not say that the parameters must be the same. There's a rule saying that the parameters shall not be omitted. It is rather unfortunate wording, because it might be interpreted in several ways. There's a CR 6692 regarding this issue.
-
-Contra opinion
-The problem is with the semantics of modified templates. For every actual parameter list, first, the template-to-be-modified is implicitly instantiated and then modified by the given modifications. If the template-to-be-modified is not defined for the actual parameters, then neither is the modified one. Of course, you are right in that this restriction could be applied for actual parameters only and need not be checked at the template-level already. However, it does not make sense to lessen the template restriction of a parameter, as implicitly, it still keeps the stronger restriction (because of the modification-semantics). Therefore, it is misleading to SEEMINGLY allow a template(present) parameter for a template where the super-template has a template(value) parameter. If allowed, the user might use a non-value template as an actual parameter and then get a runtime error, even though the template-restriction matched the one in the formal parameter of the template. Therefore, we interpret the standard in such a way that the inheritance of the parameters includes the inheritance of both the types and the template restrictions of the inherited parameters. Strengthening of template restrictions would indeed not be a problem. Lessening is.
-
-*/
-
 module Sem_1508_TemplateRestrictions_034 {
 
-	type component GeneralComp { }
-
-    type record ExampleType {
-        integer a,
-        boolean b optional
-    }
-
-    template(present) ExampleType m_baseTemplate(template(omit) integer p_myInt) := {
-        a := p_myInt,
-        b := true
-    }
-
-    template(present) ExampleType m_modifiedTemplate(template(present) integer p_myInt) modifies m_baseTemplate := {
-        a := 21
-    }
-
+    type record ExampleType {	// Exampletype record integer and a boolean
+       	integer a,
+		boolean b 
+    }	
+	
+	type component GeneralComp {
+	}
+
+	template (present) ExampleType m_baseTemplate(template (omit) integer MyintTemplate := 21) :={
+		a := MyintTemplate,	 
+		b := true
+	}
+	
 	testcase TC_Sem_1508_TemplateRestrictions_034() runs on GeneralComp {
-        if (match(valueof(m_modifiedTemplate(1).a), 21) and
-            match(valueof(m_modifiedTemplate(1).b), true)
-        ) {
-            setverdict(pass);
-        } else {
+      
+		
+		if (ispresent(m_baseTemplate.a) == true) {
+      		setverdict(pass);
+		} else {
             setverdict(fail);
-        }
-    }
+       	}
+ 	}
 
     control{
         execute(TC_Sem_1508_TemplateRestrictions_034());
     }
-}
\ No newline at end of file
+}

conformance_test/core_language_tests/positive_tests/15_templates/1508_template_restrictions/Sem_1508_TemplateRestrictions_035.ttcn

@@ -4,53 +4,35 @@
  * Adrien Kirjak
  *
  ** @version  0.0.1
- ** @purpose  1:15.8, Ensure that the restrictiveness of parameters template(omit)->template(present) is handled correctly.
- ** @verdict  pass accept, ttcn3verdict:pass
+ ** @purpose  1:15.8, Ensure that template(omit) can be parameter to template(value) if it is omit
+ ** @verdict  pass reject
  *****************************************************************/
 
-// ATTENTION: valid for TTCN-3:2013 (ETSI ES 201 873-1 V4.5.1) and newer
-// Older versions of the core languate standard didn't allow this type of 
-// modification because of restriction 15.8.c.
-
-/*
-Pro opinion:
-Test an intentional change made on the request of the STF160 in TTCN-3:2013. In particular, restriction 15.8.c was taken away from the core language specification (as marked in test case comments). This restriction did indeed mean that the tests would behave as you described, thus producing an error. However, with the restriction missing, the tests are perfectly valid. I also do not understand why you claim that it would not be possible to instantiate super-templates in these cases. Restrictions are always related to actual values and if the values satisfy both restrictions (parent and modified), there's no problem at all. And this is exactly what these test intend to verify.
-Besides, the core language specification does not say that the parameters must be the same. There's a rule saying that the parameters shall not be omitted. It is rather unfortunate wording, because it might be interpreted in several ways. There's a CR 6692 regarding this issue.
-
-Contra opinion
-The problem is with the semantics of modified templates. For every actual parameter list, first, the template-to-be-modified is implicitly instantiated and then modified by the given modifications. If the template-to-be-modified is not defined for the actual parameters, then neither is the modified one. Of course, you are right in that this restriction could be applied for actual parameters only and need not be checked at the template-level already. However, it does not make sense to lessen the template restriction of a parameter, as implicitly, it still keeps the stronger restriction (because of the modification-semantics). Therefore, it is misleading to SEEMINGLY allow a template(present) parameter for a template where the super-template has a template(value) parameter. If allowed, the user might use a non-value template as an actual parameter and then get a runtime error, even though the template-restriction matched the one in the formal parameter of the template. Therefore, we interpret the standard in such a way that the inheritance of the parameters includes the inheritance of both the types and the template restrictions of the inherited parameters. Strengthening of template restrictions would indeed not be a problem. Lessening is.
-
-*/
-
 module Sem_1508_TemplateRestrictions_035 {
 
-	type component GeneralComp { }
-
-    type record ExampleType {
-        integer a,
-        boolean b optional
-    }
-
-    template(present) ExampleType m_baseTemplate(template(omit) integer p_myInt) := {
-        a := p_myInt,
-        b := true
-    }
-
-    template(present) ExampleType m_modifiedTemplate(template integer p_myInt) modifies m_baseTemplate := {
-        a := 21
-    }
-
+    type record ExampleType {	// Exampletype record integer and a boolean
+       	integer a optional,
+		boolean b 
+    }	
+	
+	type component GeneralComp {
+	}
+
+	template (value) ExampleType m_baseTemplate(template (omit) integer MyintTemplate := omit) :={
+		a := MyintTemplate,	
+		b := true
+	}
+	
 	testcase TC_Sem_1508_TemplateRestrictions_035() runs on GeneralComp {
-        if (match(valueof(m_modifiedTemplate(1).a), 21) and
-            match(valueof(m_modifiedTemplate(1).b), true)
-        ) {
-            setverdict(pass);
-        } else {
+
+		if (match(valueof(m_baseTemplate),ExampleType:{omit,true}) == true) {
+      		setverdict(pass);
+		} else {
             setverdict(fail);
         }
-    }
+ 	}
 
     control{
         execute(TC_Sem_1508_TemplateRestrictions_035());
     }
-}
\ No newline at end of file
+}

conformance_test/core_language_tests/positive_tests/15_templates/1508_template_restrictions/Sem_1508_TemplateRestrictions_036.ttcn

@@ -4,53 +4,35 @@
  * Adrien Kirjak
  *
  ** @version  0.0.1
- ** @purpose  1:15.8, Ensure that the restrictiveness of parameters template(omit)->template(present) is handled correctly.
- ** @verdict  pass accept, ttcn3verdict:pass
+ ** @purpose  1:15.8, Ensure that template(omit) can be parameter to template(value)
+ ** @verdict  pass reject
  *****************************************************************/
 
-// ATTENTION: valid for TTCN-3:2013 (ETSI ES 201 873-1 V4.5.1) and newer
-// Older versions of the core languate standard didn't allow this type of 
-// modification because of restriction 15.8.c.
-
-/*
-Pro opinion:
-Test an intentional change made on the request of the STF160 in TTCN-3:2013. In particular, restriction 15.8.c was taken away from the core language specification (as marked in test case comments). This restriction did indeed mean that the tests would behave as you described, thus producing an error. However, with the restriction missing, the tests are perfectly valid. I also do not understand why you claim that it would not be possible to instantiate super-templates in these cases. Restrictions are always related to actual values and if the values satisfy both restrictions (parent and modified), there's no problem at all. And this is exactly what these test intend to verify.
-Besides, the core language specification does not say that the parameters must be the same. There's a rule saying that the parameters shall not be omitted. It is rather unfortunate wording, because it might be interpreted in several ways. There's a CR 6692 regarding this issue.
-
-Contra opinion
-The problem is with the semantics of modified templates. For every actual parameter list, first, the template-to-be-modified is implicitly instantiated and then modified by the given modifications. If the template-to-be-modified is not defined for the actual parameters, then neither is the modified one. Of course, you are right in that this restriction could be applied for actual parameters only and need not be checked at the template-level already. However, it does not make sense to lessen the template restriction of a parameter, as implicitly, it still keeps the stronger restriction (because of the modification-semantics). Therefore, it is misleading to SEEMINGLY allow a template(present) parameter for a template where the super-template has a template(value) parameter. If allowed, the user might use a non-value template as an actual parameter and then get a runtime error, even though the template-restriction matched the one in the formal parameter of the template. Therefore, we interpret the standard in such a way that the inheritance of the parameters includes the inheritance of both the types and the template restrictions of the inherited parameters. Strengthening of template restrictions would indeed not be a problem. Lessening is.
-
-*/
-
 module Sem_1508_TemplateRestrictions_036 {
 
-	type component GeneralComp { }
-
-    type record ExampleType {
-        integer a,
-        boolean b optional
-    }
-
-    template(present) ExampleType m_baseTemplate(template(present) integer p_myInt) := {
-        a := p_myInt,
-        b := true
-    }
-
-    template(present) ExampleType m_modifiedTemplate(template integer p_myInt) modifies m_baseTemplate := {
-        a := 21
-    }
-
+    type record ExampleType {	// Exampletype record integer and a boolean
+       	integer a,
+		boolean b 
+    }	
+	
+	type component GeneralComp {
+	}
+
+	template (value) ExampleType m_baseTemplate(template (omit) integer MyintTemplate := 1) :={
+		a := MyintTemplate,	 
+		b := true
+	}
+	
 	testcase TC_Sem_1508_TemplateRestrictions_036() runs on GeneralComp {
-        if (match(valueof(m_modifiedTemplate(1).a), 21) and
-            match(valueof(m_modifiedTemplate(1).b), true)
-        ) {
-            setverdict(pass);
-        } else {
+      
+		if (ispresent(m_baseTemplate.a) == true) {
+      		setverdict(pass);
+		} else {
             setverdict(fail);
-        }
-    }
+       	}
+ 	}
 
     control{
         execute(TC_Sem_1508_TemplateRestrictions_036());
     }
-}
\ No newline at end of file
+}