Revised the two METAR examples to avoid schema validation error.

[blchoy]

This PR was made to correct a Travis CI error in which CRUX was unable to read the IWXXM schemas from https://schemas.wmo.int/iwxxm/3.0.0/iwxxm.xsd. Interestingly when we changed the protocol from HTTPS to HTTP validation was successful. More interestingly, oXygenXML also showed exactly the same behaviour. Not sure what is happening, but would like to clean up the Build error in first place.

[moryakovdv]

Hi. Probably, ssl is used by defaut to retrieve schemas. But one of underlying schemas is not accessible by https. So, entire validation should fail.

[blchoy]

Hi. Probably, ssl is used by defaut to retrieve schemas. But one of underlying schemas is not accessible by https. So, entire validation should fail.

Hi Dimitry,

You are absolutely right. The following is a screen shot of the error on my oXygenXML Editor:

Even though I said "allow" it can still not read iwxxm.xsd, but I can read all the schema files through HTTPS on my FireFox browser.

Need to look at this more deeply, but may be later. It is Good Friday! :)

Regards, Choy

[mgoberfield]

Hmm. I never saw these errors (obviously) with OxygenXML because I used a local cache of these schemas to do the XML validation. And, as you observed, we CAN see those schemas just fine with our browsers with the https protocols.

Sorry 'bout that, Choy!

[moryakovdv]

Unfortunately, I have no Oxygen right now. Might be I took the wrong road, but there should be a way to feed it with ssl certificate chain. See the file attached (unzip it first), I downloaded it from wmo.int domain. After that Oxygen should deal with subdomain schemas.wmo.int as trusted resource. Choy, have a try to do it if possible. www-wmo-int-chain.zip

[blchoy]

Hmm. I never saw these errors (obviously) with OxygenXML

Interestingly, I cannot see the validation result on a PR, which I believe I can see previously. Did GitHub make a change to the default look of the PR page?

[blchoy]

What is the safest course of action for data producers? To use https or http?. Is this problem specific to GitHub validation software? The 'workaround', as I understand it, is the preferred method of validation which is to use a local copy of the schemas and not repeatedly query the websites for schemas.

As Dimitry have mentioned, the validator may need further setting before it can use HTTPS. I understand that schemas.wmo.int can be accessed via both HTTP and HTTPS. HTTP should have the greatest compatibility across validator configurations. However, there is also a general tendency for people to switch from using HTTP to HTTPS because of the intrinsic proof of authenticity.

I would say we should stick for HTTP right now, and move on to change to HTTPS in subsequent versions when we have more experience on validating through HTTPS.

[moryakovdv]

From my experience, you may have https validation for all of your schemas. But in some cases one of the (for example, opengis) resources failed to prolong its ssl certificate and "oops", your validation is broken. So, imho, having local copy, as Mark mentioned, is the best (and fast) way to proceed. Just keep your schemas in consistency with global ones. Also WMO balance loaders should be happy with that =)

[blchoy]

Unfortunately, I have no Oxygen right now. Might be I took the wrong road, but there should be a way to feed it with ssl certificate chain. See the file attached (unzip it first), I downloaded it from wmo.int domain. After that Oxygen should deal with subdomain schemas.wmo.int as trusted resource. Choy, have a try to do it if possible. www-wmo-int-chain.zip

Thanks Dimitry. Instead of saving the certificate I enabled the option to accept a certificate even though it may not be valid:

This time it works. So there is definitely some issue with regard to the chain. I will raise an issue to follow up.