ETSI's Bug Tracker - Part 09: Using XML with TTCN-3
View Issue Details

ID | Project | Category | View Status | Date Submitted | Last Update
0006799 | Part 09: Using XML with TTCN-3 | New Feature | public | 08-10-2014 14:49 | 07-08-2015 13:41

Reporter | Thilo Lauer |
Assigned To | Gyorgy Rethy |
Priority | normal | Severity | minor | Reproducibility | have not tried
Status | closed | Resolution | fixed |
Platform |  | OS |  | OS Version |
Product Version | v4.5.1 (published 2013-04) |
Target Version | v4.6.1 (published 2015-06) | Fixed in Version | v4.6.1 (published 2015-06) |
Clause Reference(s) | TTCN-3, Part 9
For STF discussion |
Source (company - Author) | Devoteam - Thilo Lauer

Summary | 0006799: Using the encvalue() function to build parts of a XML message or a XML matching template

Description

If the encvalue() function is used to generate parts of an XML message it can generally not be decided by the compiler/XML codec when to generate the XML header and when not.
There are situations when it is obvious but there are also situations when it is tricky or impossible to guess what the intention of the test suite developer was - in terms of adding the XML-header or not.
Therefore we suggest to add an optional parameter to encvalue() function in order to let the generation of XML header be controlled by TTCN-3 test suite developers:
encvalue(in template (value) any_type inpar,
in boolean xmlHeader:=true) return bitstring
Please have a look in the uploaded PowerPoint file, which contains an example from the LTE test suite.

Steps To Reproduce |
Additional Information |
Tags | No tags attached.

Relationships

related to | 0006815 | closed | Tomas Urban | Part 06: TTCN-3 Control Interface | TCI support for dynamic encoding parameter

Attached Files

CR_Using the encvalue() function to build parts of a XML message or a XML matching template.pptx (852,218) 08-10-2014 14:49
http://oldforge.etsi.org/mantis/file_download.php?file_id=3115&type=bug
CR6799_v1.docx (54,028) 05-11-2014 08:14
http://oldforge.etsi.org/mantis/file_download.php?file_id=3164&type=bug
CR6799_resolution_P9_v1.doc (87,552) 06-11-2014 15:18
http://oldforge.etsi.org/mantis/file_download.php?file_id=3180&type=bug
CR6799_resolution_P9_v2.doc (89,088) 06-11-2014 16:00
http://oldforge.etsi.org/mantis/file_download.php?file_id=3181&type=bug
CR6799_v2.docx (54,316) 07-11-2014 08:46
http://oldforge.etsi.org/mantis/file_download.php?file_id=3182&type=bug
CR6799_resolution_P9_v3.doc (90,112) 21-11-2014 10:23
http://oldforge.etsi.org/mantis/file_download.php?file_id=3186&type=bug

Issue History
Date Modified | Username | Field | Change
08-10-2014 14:49 | Thilo Lauer | New Issue |
08-10-2014 14:49 | Thilo Lauer | File Added: CR_Using the encvalue() function to build parts of a XML message or a XML matching template.pptx |
08-10-2014 16:42 | Jacob Wieland - Spirent | Note Added: 0012304 |
09-10-2014 16:14 | Tomas Urban | Note Added: 0012333 |
09-10-2014 16:15 | Tomas Urban | Note Edited: 0012333 | bug_revision_view_page.php?bugnote_id=12333#r81
10-10-2014 09:42 | Jacob Wieland - Spirent | Note Added: 0012341 |
10-10-2014 10:17 | Tomas Urban | Note Added: 0012345 |
10-10-2014 10:32 | Thilo Lauer | Note Added: 0012348 |
10-10-2014 11:09 | Jacob Wieland - Spirent | Note Added: 0012357 |
10-10-2014 11:37 | Tomas Urban | Note Added: 0012358 |
10-10-2014 11:56 | Jacob Wieland - Spirent | Note Added: 0012361 |
03-11-2014 10:04 | Gyorgy Rethy | Target Version | => v4.6.1 (published 2015-06)
03-11-2014 15:43 | Gyorgy Rethy | Note Added: 0012381 |
03-11-2014 15:44 | Gyorgy Rethy | Assigned To | => Tomas Urban
03-11-2014 15:44 | Gyorgy Rethy | Status | new => assigned
03-11-2014 15:58 | Jacob Wieland - Spirent | Note Added: 0012382 |
04-11-2014 16:45 | Tomas Urban | Note Added: 0012408 |
05-11-2014 08:14 | Tomas Urban | File Added: CR6799_v1.docx |
05-11-2014 08:16 | Tomas Urban | Note Added: 0012412 |
05-11-2014 08:16 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
05-11-2014 08:16 | Tomas Urban | Status | assigned => confirmed
06-11-2014 13:39 | Gyorgy Rethy | Note Added: 0012467 |
06-11-2014 15:17 | Gyorgy Rethy | File Added: CR6799_resolution_v1.doc |
06-11-2014 15:18 | Gyorgy Rethy | File Deleted: CR6799_resolution_v1.doc |
06-11-2014 15:18 | Gyorgy Rethy | File Added: CR6799_resolution_P9_v1.doc |
06-11-2014 15:19 | Gyorgy Rethy | Note Added: 0012474 |
06-11-2014 15:19 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
06-11-2014 16:00 | Tomas Urban | File Added: CR6799_resolution_P9_v2.doc |
06-11-2014 16:02 | Tomas Urban | Note Added: 0012477 |
06-11-2014 16:02 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
07-11-2014 08:46 | Tomas Urban | File Added: CR6799_v2.docx |
07-11-2014 08:47 | Tomas Urban | Note Added: 0012478 |
07-11-2014 08:58 | Tomas Urban | Relationship added | related to 0006815
21-11-2014 10:23 | Gyorgy Rethy | File Added: CR6799_resolution_P9_v3.doc |
21-11-2014 10:25 | Gyorgy Rethy | Note Added: 0012512 |
21-11-2014 10:25 | Gyorgy Rethy | Assigned To | Gyorgy Rethy => Tomas Urban
21-11-2014 15:19 | Tomas Urban | Note Added: 0012514 |
21-11-2014 15:19 | Tomas Urban | Status | confirmed => resolved
21-11-2014 15:19 | Tomas Urban | Fixed in Version | => v4.6.1 (published 2015-06)
21-11-2014 15:19 | Tomas Urban | Resolution | open => fixed
21-11-2014 15:19 | Tomas Urban | Assigned To | Tomas Urban => Gyorgy Rethy
31-12-2014 11:51 | Gyorgy Rethy | Note Added: 0012597 |
31-12-2014 11:51 | Gyorgy Rethy | Status | resolved => closed
07-08-2015 13:41 | Gyorgy Rethy | Note Added: 0013147 |

Notes

(0012304)
Jacob Wieland - Spirent
08-10-2014 16:42

I am strongly opposed to this kind of specific-problem-resolution-approach. I would rather have a map-param-like solution or something else where you can pass additional parameters to the encoder. Similar problems can happen in any encoding (e.g. whether or not to include BOMs or whether or not to pretty-print the XML and so forth), so I would opt for a more general approach to this problem.

(0012333)
Tomas Urban
09-10-2014 16:14 (edited on: 09-10-2014 16:15)

Maybe we could overload the @encoded symbol proposed in 0006736 so that it can be used in templates for sending. TCI update would be required then too. Would it solve the problem?

(0012341)
Jacob Wieland - Spirent
10-10-2014 09:42

This is too vague a proposal. Please give an example.

(0012345)
Tomas Urban
10-10-2014 10:17

Assuming we have a complex type with anyElement and a real element we would like to put into in its encoded form mapped into the following TTCN-3 definitions:
type record Envelope {
XSD.String elem
}
with {
variant "name as uncapitalized";
variant(elem) "anyElement"
}
type record Payload {
...
}
with {
variant "name as uncapitalized"
}
the template for sending could be defined in the following way:
template Payload m_payload := {...}
template Envelope m_msg := {
elem := @encoded m_payload
}
Like in case of matching, the @encoding modifier would allow to insert a content of an arbitrary type into a template field of a string type. The modifier would be interpretted by the codec as an instruction to encode the value of the arbitrary type first, tranform it to the target string type and perform additional encoding task (if necessary) to insert the string to the encoded PDU.

(0012348)
Thilo Lauer
10-10-2014 10:32

Originally TTCN was designed to make it obvious from the TTCN source code what is really done with received/sent messages and that everyone can easily read that code. This was one of the reasons that TTCN-3 does not have automatic type conversion (e.g. between float and integer, between bitstring, hexstring and octetstring, etc.) For all this stuff you need an extra type conversion function! On the other side more and more complexity is passed to the compiler with all these "@modifiers". Does a normal TTCN-3 user still understand what is really going on????
!!! We strongly oppose to such a solution !!!

(0012357)
Jacob Wieland - Spirent
10-10-2014 11:09

@Tomas: I think what you are describing is already allowed with the @encoded matching mechanism, but I don't see the connection to the issue at hand how the encoder should know whether or not to include the header.
@Thilo: the modifiers are a result/solution of/to years of backward-compatibility problems caused by new features which need new keywords because new keywords always potentially break old stuff. The modifiers solve this as they cannot clash with existing keywords and identifiers and thus are a clean way of introducing new keywords.
That said, I don't think that forcing the user to write longer and repetitive code for every little thing they do will raise the acceptance of TTCN-3. If the semantics of an explicitly-written-down feature is clearly explained in the standard, it should not be a problem. There is no 'implicit conversion' going on but an explicit one. Anyway, I still don't see a solution to the problem at hand.
What about a variant attribute for the template to be sent controlling whether the codec should add a header or not? I think this would be much more in sync with existing TTCN-3 approaches.

(0012358)
Tomas Urban
10-10-2014 11:37

At the moment, @encoded is specified for matching only. My proposal is to use it for sending as well. In the given example, the codec would get RecordValue representing the Entity value as usually. When encoding the value content, the getField("elem") call would return EncodedValue (containing a reference to universal string as the target type and RecordValue representing the data source of the Payload type) instead of a UniversalCharstringValue.
The difference comparing to the original proposal made by Thilo is that there's one encoding call instead of two. And since the codec is well aware that the @encoded content lies inside of an XML envelope, it can easily use appropriate encoding without the XML-header and even take advantage of other features already used within the produced XML document (such as namespace prefixes).

(0012361)
Jacob Wieland - Spirent
10-10-2014 11:56

For this specific problem, this would indeed be an elegant solution, though I still think that making it more explicit, as Thilo wants to be enforced, is probably not such a bad idea (Otherwise, the decision is shifted to the implementer of the codec and that again can yield different results from implementation to implementation (one implementation might simply delegate to another codec and that codec always adds the header and one might do it differently).

(0012381)
Gyorgy Rethy
03-11-2014 15:43

STF discussion: preferred way is to add an optional string parameter to encvalue/decvalue for codec conrtol purposes in part-1. In part-9 a "noXmlHeader" and if later needed, more instructions will be defined.

(0012382)
Jacob Wieland - Spirent
03-11-2014 15:58

How is that additional parameter to be transported to tciEncode? Adding a new parameter there would break a lot of code? Also, can we at least make the part-1 solution less specific (i.e. allow any type to be passed so that for other codecs this can be reused?) Otherwise, all information will be encoded in a string and that string needs to be parsed by the codec which seems overly complicated.

(0012408)
Tomas Urban
04-11-2014 16:45

Just a couple of comments:
1. There are two options for handling it on TCI level: either extending the tciEncode function (which has the drawback that old libraries have to be recompiled) or introducing a new function for handling the parameterized call (tciEncodeParam). In any case, a new CR has to be made for part 6.
2. Character strings are already used for static encoding instructions in TTCN-3 attributes. Our intention was to follow the same paradigm for dynamic encoding instructions as well. Besides, we don't expect that this parameter will be widely used and if used, it probably won't contain very complicated content. Using the charstring type also saves the user from making type checks in their codecs. In case our assumptions turns out to be wrong, it is always possible to lift the type restriction and allow values of all types in the next version of the TTCN-3 specification.

(0012412)
Tomas Urban
05-11-2014 08:16

Resolution proposal uploaded. Please review. If you find the resolution acceptable, please create a CR for TCI changes and assign it to me.

(0012467)
Gyorgy Rethy
06-11-2014 13:39

Part-1 addition is OK with me.

(0012474)
Gyorgy Rethy
06-11-2014 15:19

CR6799_resolution_P9_v1.doc: Part-9 portion of the solution. Please check.

(0012477)
Tomas Urban
06-11-2014 16:02

According to our discussion I changed the part concerning xmlns and made a couple of minor editorial changes (removed variant attribute from the syntax, changed quotation marks, swapped neither and nor). Please review.

(0012478)
Tomas Urban
07-11-2014 08:47

The encoding_info parameter changed to universal string for additional flexibility.

(0012512)
Gyorgy Rethy
21-11-2014 10:25

Part-1 resolution in CR6799_v2.docx is OK with me. Please check Part-9 resolution in CR6799_resolution_P9_v3.doc. If OK with you, CR can directly be set to resolved.

(0012514)
Tomas Urban
21-11-2014 15:19

I have no objections. The resolution v3 can be added to the part 9.

(0012597)
Gyorgy Rethy
31-12-2014 11:51

Added to draft V4.5.3

(0013147)
Gyorgy Rethy
07-08-2015 13:41

Implemented in interim draft V4.7.2 uploaded to MTS's drafts area (file es_20187301v040702_e.docx of CR 7085).