Logo etsi

ETSI's Bug Tracker
Main | My View | View Issues | Change Log | Roadmap | Stop monitoring 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
0005129ETSI TTCN-3 Quality CheckerT3Q toolpublic28-04-2009 14:2821-02-2012 15:24
ReporterPhilip Makedonski 
Assigned ToPhilip Makedonski 
PrioritynormalSeverityfeatureReproducibilityN/A
StatusfeedbackResolutionreopened 
PlatformOSOS Version
Product Version 
Target VersionRelease 0.4.0Fixed in VersionRelease 0.4.0 
Summary0005129: Discussion: Further naming conventions
DescriptionThe initial set of naming conventions has been taken from http://www.ttcn-3.org/NamingConventions.htm. [^] Apart from some confusion about the naming conventions for templates and templates with matching expressions, it has become apparent that certain further naming conventions may be desirable as well, such as local constants and modified / modifying templates.

What is the overall opinion?

The naming conventions checking is relatively easy to extend, so with minor effort further naming conventions can be added. It remains to be clarified whether naming conventions for modified or modifying templates (or perhaps both) are desired.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
(0008702)
Philip Makedonski (developer)
01-06-2009 11:02

 The modifying (derived) templates shall be taken into consideration (default "d" flag for "derived"). This should be checked against the context. Local constants as well.
(0010549)
Miguel Angel Reina Ortega (reporter)
16-02-2012 16:06

 Derived message templates with wildcards are checked against derived message template (without wildcards).

An extra check should be the following:

A derived message template modifies a message template (md -> m)
A derived message template with wildcards modifies a message template with wildcards (mdw -> mw)
(0010551)
Philip Makedonski (developer)
21-02-2012 12:41

 Is what you propose only a naming conventions check (whether the template name reflects the fact that it modifies a template with or without wildcards) or is it more of a content consistency check (whether there are templates with or without templates that modify templates with or without wildcards)? In case of the latter, it should be discussed separately. In case of the former, it may need to be elaborated on further, e.g. which distinctive cases should be considered and how to avoid possible conflicts with other naming conventions. From my understanding, there would be 4 cases:
1. Derived template without wildcards modifies a template without wildcards (currently m_)
2. Derived template with wildcards modifies a template without wildcards (currently mw_)
3. Derived template without wildcards modifies a template with wildcards (currently will become mw_)
4. Derived template with wildcards modifies a template with wildcards (currently mw_)
(0010553)
Miguel Angel Reina Ortega (reporter)
21-02-2012 15:24

 It is both. Regarding the naming convention, a derived template with wildcards name (i.e. mdw_myDerivedTemplateWithWildcards)is checked against the derived template without wildcards name set in the config file. The reason is, I am guessing, that the wildcards are contained into the modified template and not in the modified fields.
The above problem is linked to the second one, content consistency check. To solve both, I think an extra check is needed (that's my proposal).
Then, regarding your cases:
1. md_ modifies m_ ==> OK
2. mdw_ modifies m_ ==> OK (if modified fields contain wildcards, at least one)
3. md_ modifies mw_ ==> Not OK (it should modify all fields containing wildcards, which becomes difficult to track, and confusing)
4. mdw_ modifies mw_ ==> OK

- Issue History
Date Modified Username Field Change
28-04-2009 14:28 Philip Makedonski New Issue
28-04-2009 14:28 Philip Makedonski Status new => assigned
28-04-2009 14:28 Philip Makedonski Assigned To => Philip Makedonski
01-06-2009 11:02 Philip Makedonski Note Added: 0008702
07-08-2009 15:14 Philip Makedonski Status assigned => resolved
07-08-2009 15:14 Philip Makedonski Resolution open => fixed
07-08-2009 15:14 Philip Makedonski Projection none => tweak
07-08-2009 15:14 Philip Makedonski Fixed in Version => Release 0.4.0
07-08-2009 15:14 Philip Makedonski Target Version => Release 0.4.0
16-02-2012 16:06 Miguel Angel Reina Ortega Status resolved => feedback
16-02-2012 16:06 Miguel Angel Reina Ortega Resolution fixed => reopened
16-02-2012 16:06 Miguel Angel Reina Ortega Note Added: 0010549
21-02-2012 12:41 Philip Makedonski Note Added: 0010551
21-02-2012 15:24 Miguel Angel Reina Ortega Note Added: 0010553

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