Possible mistake in Space Weather Advisory in element Advisory Number

[Mattonius5]

SpaceWxAdvisory.xsd since ver. IWXXM 2021-2 added "nillable" to element "advisoryNumber" of type "iwxxm:StringWithNilReasonType" while being optional (minOccurs = 0). Element "replacedAdvisoryNumber" remained intact.
I believe it should be the other way around, "replacedAdvisoryNumber" should be nillable with nil reason while "advisoryNumber" should be mandatory of type "String". Look at the Annex 3, table A2-3, it clearly states that "advisoryNumber" shall be mandatory and "replacedAdvisoryNumber" shall be used under specific conditions.

Any SWX advisory without Advisory number shall be treated as invalid.
Can anyone shine light into this ambiguity?
Was this change made for the sole purpose not to change Schematron rule "SpaceWeatherAdvisory-2" which checks for its presence?

[blchoy]

Hi Matouš,

Thank you for your detailed analysis. Your observation has a point, but there is a reason for doing so.

Remember most of the current IWXXM reports have their own TAC cousins, including SWA. The pair are having the same content as well as report format. For iwxxm:advisoryNumber its presence is mandatory (and hence the presence of the schematron rule you pointed out), but in some cases its TAC form will not have this element. Under these situations, we will have to make iwxxm:advisoryNumber nil with a nilReason.

Now for those XML elements having the AssociationAttributeGroup, the attribute nilReason can be used directly (see #19), but for those which do not, they will need to use xsi:nil="true" in the instance which is enabled by nillable="true" in the schema. The team has decided that to avoid ambiguity, as long as a nilReason is expected to be used, nillable="true" will be put in place no matter it is required or not. So this is why you can see it in iwxxm:advisoryNumber but not iwxxm:replacedAdvisoryNumber (which is optional and the XML tag can be absence).

I agree that this is not good practice, but at least it serve the purpose.

[Mattonius5]

Thank you for the clarification.

Many instances across various IWXXM messages require certain elements filled with nilReason while the element itself cannot be nillable. Thus, I agree that nilReason should be used only alongside the nillable element. It is probably a move in the correct direction. However,

I am concerned about this approach. There are reasons for certain fields being mandatory in TAC, such as "Advisory number". I would prefer generating TranslationFailedTac IWXXM message instead of allowing invalid TAC messages to be translated into IWXXM. The goal should be to strengthen rules, not loosen them, thus encouraging operators to send valid TAC messages.

[blchoy]

Thank you for the suggestion. You may want to know that TAC will be phased out in the coming years. While their IWXXM cousins will remain, their value will depreciate when their SWIM-capable siblings arrived. We will keep an eye on this but unless absolutely needed we will not make further changes to the TAC derived IWXXM reports.