Closed mgoberfield closed 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.
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:
Except rule SIGMET.SIGMET-8 fires:
which my beautiful XML clearly does! :)
My workaround is to define the 'iwxxm' prefix to make the rule happy:
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.
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.
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.
This is fixed in 3.0-dev.
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