Logo etsi

ETSI's Bug Tracker
Main | My View | View Issues | Change Log | Roadmap | Monitor project
  
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
0006799Part 09: Using XML with TTCN-3New Featurepublic08-10-2014 14:4907-08-2015 13:41
ReporterThilo Lauer 
Assigned ToGyorgy Rethy 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionfixed 
PlatformOSOS Version
Product Versionv4.5.1 (published 2013-04) 
Target Versionv4.6.1 (published 2015-06)Fixed in Versionv4.6.1 (published 2015-06) 
Summary0006799: Using the encvalue() function to build parts of a XML message or a XML matching template
DescriptionIf 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.
TagsNo tags attached.
Clause Reference(s)TTCN-3, Part 9
For STF discussion
Source (company - Author) Devoteam - Thilo Lauer
Attached Filespptx file icon CR_Using the encvalue() function to build parts of a XML message or a XML matching template.pptx [^] (852,218 bytes) 08-10-2014 14:49
docx file icon CR6799_v1.docx [^] (54,028 bytes) 05-11-2014 08:14
doc file icon CR6799_resolution_P9_v1.doc [^] (87,552 bytes) 06-11-2014 15:18
doc file icon CR6799_resolution_P9_v2.doc [^] (89,088 bytes) 06-11-2014 16:00
docx file icon CR6799_v2.docx [^] (54,316 bytes) 07-11-2014 08:46
doc file icon CR6799_resolution_P9_v3.doc [^] (90,112 bytes) 21-11-2014 10:23

- Relationships
related to 0006815closedTomas Urban Part 06: TTCN-3 Control Interface TCI support for dynamic encoding parameter 

-  Notes
(0012304)
Jacob Wieland - Spirent (reporter)
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 (developer)
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 (reporter)
10-10-2014 09:42

 This is too vague a proposal. Please give an example.
(0012345)
Tomas Urban (developer)
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 (reporter)
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 (reporter)
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 (developer)
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 (reporter)
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 (reporter)
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 (reporter)
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 (developer)
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 (developer)
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 (reporter)
06-11-2014 13:39

 Part-1 addition is OK with me.
(0012474)
Gyorgy Rethy (reporter)
06-11-2014 15:19

 CR6799_resolution_P9_v1.doc: Part-9 portion of the solution. Please check.
(0012477)
Tomas Urban (developer)
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 (developer)
07-11-2014 08:47

 The encoding_info parameter changed to universal string for additional flexibility.
(0012512)
Gyorgy Rethy (reporter)
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 (developer)
21-11-2014 15:19

 I have no objections. The resolution v3 can be added to the part 9.
(0012597)
Gyorgy Rethy (reporter)
31-12-2014 11:51

 Added to draft V4.5.3
(0013147)
Gyorgy Rethy (reporter)
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).

- 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 View Revisions
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

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