Since I haven't heard anything on this issue in a long time, I'm closing it. As far as I recall, almost every single error is 100% correct and has to do with errors in teh schema themselves.

Bulk move all schema issues to 'LATER' because they take a lot of time to re-verify and they rarely make any progress. :|

bfitzpat_rh Unfortunately all of those errors appear to be problems in either the quickstart itself, or the schema. None of those errors seem to be eclipse errors. The errors starting with cvc-complex-type.2.4.a indicate that your xml file is not strictly following the schema (ie, the schema is saying it needs some sub-elements, and you've provided none. Your xml is incomplete and is not valid as per the schema).

The other bugs (Referenced file contains errors) have to do with errors in the schemas themselves, and, most often, have to do with the schemas using relative locations, which they should never do, because it assumes all schema are colocated, and they rarely are anymore.

So it seems you have two tasks here:
1) Remove all relative schemaLocation tags and replace them with schemaLocation tags that point to the actual home of the schema
2) Fix the quickstarts to not leave out elements that the schema say are required.

Unfortunately, that's the best I can offer you. If you'd prefer to outsource that task, I suggest you open a jira to the switchyard runtime team to make sure all xsd validate and no relative schemaLocation tags are used anywhere. This may turn out to be really hard, though, because you'll have to fight with other schema providers (http://docs.oasis-open.org/opencsa/sca-assembly/sca-1.1-cd06.xsd) to also not use relative paths.

https is what most moved to, even for public.

But ignoring that this is what osgi.org decided to do - using https instead of http.

Thus simply asking if the issue Rob refer above is the only thing that is there in your usecase of it goes beyond that.

Max, I have no clue what you're referring to as far as http to https goes. Why would we want https paths to publicly accessible URLs?

bfitzpat_rh I did not ask if we could change the schemas in the runtimes, I asked if the issues you had went away if you changed from http to https ?

i.e. are the only issue you have because of missing http->https redirects ?

I don't think that it does. I don't know that we can ask our runtime (in this case SwitchYard) to change their schemas, which work just fine, because of a validation issue (where the XSD validator is being overly zealous) in the tooling.

tcunning@redhat.com or lheinema@redhat.com wdyt?

bfitzpat_rh if rob.stryker is right the issue is purely about using actual correct (non-redirected) xsd references. Does that fix it for your usecase ?

I've found the problem with the above situation, and opened a bugzilla for it: https://bugs.eclipse.org/bugs/show_bug.cgi?id=473971

Overall, seems unrelated to this issue, but I'm getting desperate and just throwing all xml stuff in teh same bucket

I'm not sure this is related either, but it's possing me off, so I'm grouping it with the other xml schema validation stuff.

The following XML successfully validates:

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0" 
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
       xsi:schemaLocation="
       http://camel.apache.org/schema/blueprint  http://camel.apache.org/schema/blueprint/camel-blueprint.xsd">
</blueprint>

The following fails to validate:

<?xml version="1.0" encoding="UTF-8"?>
<blueprint xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0" 
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
       xsi:schemaLocation="
       http://www.osgi.org/xmlns/blueprint/v1.0.0  http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd 
       http://camel.apache.org/schema/blueprint  http://camel.apache.org/schema/blueprint/camel-blueprint.xsd">
       
</blueprint>

The only difference is the addition of http://www.osgi.org/xmlns/blueprint/v1.0.0 http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd in the schemaLocation field.