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