Pros:
- Simple
- No XML Schema enforcement when stepping version and version number is concealed for user.
- Do no use.
Change the Schema location and keep the namespace.
Pros:
- Good för maintaining backward compability. No depending XML files needs to be altered, simply upgrade implementing jar.
- Cannot tell from the XML file which implementing jar version is used.
- Use this technique to handle minor version upgrade.
Example:
http://camel.apache.org/schema/spring/camel-spring-1.6.X.xsd, in version 1.6.0-1.6.3 is the same targetNamespace used.
Change the Schema location and the namespace.
Pros:
- Forces the user to upgrade the client code, when stepping version. Hard versioning control, no chanse to make misstake.
- No seamless upgrade. Upgrade will cost.
- Use this when stepping major version.
For you using JAXB, is it a good reminder that the namspace versionnumber is direclty reflected in the package name. So when uppgrading and if the depending generated code has changed namespace, i.e. package name will the depending code not compile. This can be a advantage since it will directly be apparent where in your code you have the dependencies.
No comments:
Post a Comment