search

wmo-im / iwxxm

XML schema and Schematron for aviation weather data exchange
https://old.wmo.int/wiswiki/tiki-index.php%3Fpage=TT-AvXML
48 stars 22 forks source link

Reuse featureType Report attribute? #139

Closed mgoberfield closed 6 months ago

mgoberfield commented 5 years ago

With the new treatment off-nominal cases, the permissibleUseage and permissibleUsageReason attributes are better utilized except for permissbleUsageSupplementary attribute, which seems superfluous now. Propose that it be dropped from the Report featureType, or re-purposed (renamed to something more generic) to allow informational message on off-nominal cases, e.g. reason for TAC translation failure.

blchoy commented 5 years ago

permissibleUsageSupplementary is suppose to qualify permissibleUsageReason (which can only be TEST or EXERCISE) and I think there is a value to have it there. I agree with you that there is currently no way to say why a translation failed but I am not too sure this information is useful to downstream users, especially there is no rule or guideline on how to write error messages. For a lazy programmer the reason could be simply "SYNTAX ERROR"!

jkorosi commented 5 years ago

I think it would be useful to enhance translation metadata. Just imagine that you are an operator in switching system, responsible for translation, who are able to do a correction of reports if it is needed and/or it is reasonable. I know that we already have original TAC message included when translation failed, but I think that it will be also helpful to include (optionally) the reason why translation failed. I think it will save investigation time for them.

Maybe it will be also beneficial to include translated report also in the case of successful translation for checking and testing purposes. I know that the intention is to replace TAC, but this can be a way how to help user to somehow cover transition process from TAC to IWXXM. At least it will be easier to understand what is/should be reported in the report on a few lines.

This all can be done by inserting a comments into IWXXM reports, and I already implement similar functionality in our software, but I will be happy to re-implement it in a standardized way.

mgoberfield commented 5 years ago

If we are to have such a generic attribute for supplementary/additive content, I'd recommend a constraint on its use to only NON-OPERATIONAL or "translation failed" messages. I would not want to introduce a back-door to allow TAC messages to appear in the product even in normal situations.

As Jan correctly points out, we should help the data producers understand how the current TAC forms are represented in IWXXM. The examples in the GitHub iwxxm-translation repository is a start. And I intend to start on #82 soon.

jkorosi commented 5 years ago

I have additional question according to "translation failed" messages. The documentation says

The full, original TAC that could not be translated. When translation fails only the report type (i.e, SIGMET or METAR), translation information and other basic report metadata should be provided. In this case no translated content will be included other than the original TAC. Translation is considered to have failed when either not all of the TAC could be understood by the translation software or not all of the mandatory TAC content could be found. Permissible usage may be set as normal and TAC that failed translation may still be used for operational purposes, but under no circumstances should partially translated content be distributed or marked as operational

I think that remark section should be excluded from this condition Translation is considered to have failed when either not all of the TAC could be understood by the translation software or not all of the mandatory TAC content could be found.

Am I right?

blchoy commented 5 years ago

@jkorosi: I think that remark section should be excluded from this condition

You are right. The TAC mentioned so far are "Annex 3 compliant TAC" which has no RMK section.

blchoy commented 5 years ago

@mgoberfield : If we are to have such a generic attribute for supplementary/additive content, I'd recommend a constraint on its use to only NON-OPERATIONAL or "translation failed" messages. I would not want to introduce a back-door to allow TAC messages to appear in the product even in normal situations.

Agreed. Will modify the schematron rules accordingly.

As Jan correctly points out, we should help the data producers understand how the current TAC forms are represented in IWXXM.

As this was developed by a workstream I will incorporate this into my summary of changes in IWXXM 3.0 to be presented in the upcoming IWXXM workshop to seek other's view before implementation.