Valentin Baciu wrote:

If in the future this type of version driven schema location becomes widespread, and use case 2 is preferred (as in the XSLT case), perhaps we could: - enhance the XML catalog resolver to directly support this scenario - generalize the XSLT custom resolver approach suggested by Dave and make it available as API
        - come up with some other mechanism to support this scenario
Actually, Valentin, this common namespace between minor versions is pretty standard within the B2B space. Standard organizations like STAR, OAGI, ACCORD, HR-XML, UNCEFACT, etc all use the same namespace for minor version changes to a schemas, they only tend to change the namespace when there is a major version change. The only issue with this is when a user has an older versions say (STAR 4.0.4, but a trading partern uses STAR 4.1.4), what may validate in one person's instance doesn't necessarily validate in another person's instance. This is where the custom resolver approach comes in handy to help determine which schema should actually be used to do the validation. Most of these B2B schemas have a version attribute on their XML's, so in combination with the namespace and the version attribute it's easier to figure out which one to use.

Ideally the OASIS would address this in the XML Catalog, but that doesn't appear to be likely.

Dave
_______________________________________________
wtp-dev mailing list
wtp-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/wtp-dev

Reply via email to