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

Schematron rules hardwired 'iwxxm' prefix into assertion tests #210

Closed mgoberfield closed 4 years ago

mgoberfield commented 4 years ago

Schematron rules SIGMET.SIGMET-[8,9], TropicalCycloneSIGMET.TropicalCycloneSIGMET-[3,4], and VolcanicAshSIGMET.VolcanicAsh-[4,5] use ../*[name() != 'iwxxm:....' construct in assertion rules.

If the SIGMET document has xmlns="http://icao.int/iwxxm/3.0" declared, then the aforementioned assertions are triggered. Also, a data producer could be of the pathological sort and define IWXXM namespace prefix like so,

xmlns:ns1="http://icao.int/iwxxm/3.0"

These assertions would also fire in such a case.

Given that the remaining rules seem to be agnostic on whether default namespace is defined to be IWXXM or can be a different prefix other than 'iwxxm', these SIGMET assertions seem too restrictive.

Very respectfully submitted,

mark

blchoy commented 4 years ago

I think I have mentioned similar finding elsewhere. In fact, when you have a collective of, say, METAR messages. If they are in different IWXXM versions, then each of them should be in different namespaces and hence different namespace prefixes. This actually complicates the creation of collectives as one will have to change the namespace of individual METAR message. As you have mentioned, that the existing schematron rules won't work too.

I will mark this as a known problem of IWXXM 3.0 and will need improvement before releasing the next version.

mgoberfield commented 4 years ago

Hi Choy,

I re-read issue #162 carefully. I don't pretend to understand all of the nuances that were made in the discussion--except to say I like Enrico's responses--but I think this issue I've raised here is of another type. The assertions containing ../*[name() != 'iwxxm:....' require the prefix 'iwxxm' in order not to fire.

So, if the default namespace is IWXXM, this should be perfectly acceptable XML:

Issue-210-1

Except rule SIGMET.SIGMET-8 fires:

Issue-210-2

which my beautiful XML clearly does! :)

My workaround is to define the 'iwxxm' prefix to make the rule happy:

Issue-210-3

Given that there is a workaround, we can fix this at a later time.

Noticed that you've changed the title. Okay, but only the SIGMET rules have this issue.

blchoy commented 4 years ago

Noticed that you've changed the title. Okay, but only the SIGMET rules have this issue.

Thanks for pointing out. In any case the root cause is the hard coding of the namespace prefix of "iwxxm" in the rules and that has to be fixed to accommodate possible use of other namespace prefixes. Unfortunately I am busy working on the WAFC SIGWX F/C and will only be able to come back to this in the latter half of April which I will also take a look at Am79 changes.

blchoy commented 4 years ago

Finally I have time to take a look at this. The simplest solution is to use local-name() instead of name() and remove the namespace prefix. This will be implemented in subsequent update.

blchoy commented 4 years ago

This is fixed in 3.0-dev.