ISO country code based FM bearers in an XSI to SI transform

[andybee]

FM bearers such as fm:gb.c123.09580 were included and therefore considered valid in the legacy XSI specification, but are now no longer acceptable as part of the deprecation of using an ISO code in place of working out a GCC value based on geographic location.

It has been suggested the XSLT therefore remove these from an XSI to SI transform.

XSLT v1 is unable to use regex to match a value, limiting the ability to reliably spot the invalid FM bearers and remove the entire element.

A proposed "hack" to get close to the intended behaviour is featured in the branch proposed-iso-fm-bearer-removal-hack. This checks an FM bearers string length as an ISO country based one is 1 character too short.

This of course allows for a whole host of other weird behaviour, but it's the closest I think we can get if others feel the original problem is a genuine concern.

I'd appreciate feedback from others on if this is worth merging in to v2 or not.

[nickpiggott]

I think this "hack" is actually very legitimate. The specification says an FM bearer must be constructed as:

fm:..

and that:

"Frequency on which the service broadcast is received, formatted to 5 characters in units of 100 KHz. Frequencies below 100 MHz shall be supplied with a leading zero, for example 95,8 MHz would be represented as 09580, 104,9 MHz as 10490."

and that PI code shall be a 4 character hexadecimal value, and that the GCC shall be a 3 character hexadecimal value.

Therefore a valid FM bearer must be exactly 17 characters in length. Any other length, regardless of whether it is using GCC or not, is invalid.

This approach would also trap situations where bearers have been formed using the 2-character ECC value (from RDS) rather than the correct 3- character GCC.

I think your approach is correct and helpful.

[andybee]

Thanks for useful feedback.

The biggest concern I have for including this is around consistency in approach. The document to date does not attempt to validate the content, it simply spots valid patterns with a view to transforming - but continues to allow "invalid" attributes, child elements etc. regardless.

This adds a validation step, albeit for a good reason.

I'm just wary that we don't deviate from the approach of avoiding validation wherever possible beyond this.

If there's no objection to the inclusion of this rule, I'm happy to merge the branch. This issue will be a useful record of the explicit circumstance this came about as a way to try and justify not including further validation steps.

[magicbadger]

Agree, it's a useful addition.

I would not say it's a shift in focus to validation. In order to translate data one must first understand how it is currently formatted, and that may include an element of enforcing a particular pattern or structure in order to properly do this.

[andybee]

Thanks for your feedback @magicbadger.

I guess the inclusion of an if statement to ensure a string begins with fm: and is a certain length is just a slight extension of the existing checks for element types to begin a transform.

I'd like to draw this discussion to a close as soon as possible so I can complete v2 and merge to master, so I'm going to allow seven days for others to feedback, else I'll merge the branch and close this issue.