What does ONVIF version 1.0, 1.1, 1.2, 2.0 generally means? Why version 1.0, 1.1, 1.2, 2.0 can be incompatible?
The design principle of ONVIF is "backward compatible". The commonly referred incompatibility issues among version 1.0, 1.1, 1.2, and 2.0 can be summarized to the following issues:
- The XML namespace of the Imaging service has changed during the transition from 1.0 to 2.0. This makes Imaging service 1.0 and 2.0 two sets of entirely different commands.
- The XML namespace of the PTZ service has changed during the transition from 1.0 to 2.0. This makes PTZ service 1.0 and 2.0 two sets of entirely different commands.
- There are some structural changes of Device Management service during the transition from 1.0 to 2.0. Among the changes, I/O related commands are moved to Device IO XML namespace in 2.0, while they are in Device Management during 1.0. This changed XML namespace makes 1.0 and 2.0 two sets of entirely different commands.
Other parts of ONVIF specification such as Media service do not suffer from similar issues because XML namespace is not changed. As to the real cause about why make such potentially incompatible XML namespace changes, we think it's because ONVIF is very prudent about specification definition. In WSDL, if specification 1.0 defines some XML element to be "mandatory", then it cannot be later changed to "optional" in 2.0, because doing so will violate the principle of backward compatibility. To solve such problem, the most clean way is to create an entirely different XML namespace to separate old commands and new commands, although they look pretty much alike in everyway. If you choose to implement both sets (new and old) of command then you can achieve maximum compatibility. Observing other ONVIF specifications, if it's not absolutely necessary, ONVIF wouldn't choose to use a different XML namespace between old and new versions of specification, and those specifications are readily backward-compatible.
Regardless, if one carefully read and understand those minor differences between versions of specification, it's completely feasible in technical sense to write an ONVIF implmentation that supports all versions of specification, or to perform automatic ONVIF version detection.
It's noteworthy that because ONVIF specification is written by human, there can be errors (e.g. bugs). Thus in some minor version specification updates, ONVIF will note the errors from previous version of specification and make relevant corrections, so you can't trust it with 100%. Just like laws, which requires human to interpret the real meaning behind the text. Interpretation could further change or evolve over time, but in theory it will become more and more clear.
XML namespace is a naming method used by the ONVIF underlying SOAP transport. For example, If we use timg10 to represent the namespace of Imaging service 1.0, which is "http://www.onvif.org/ver10/imaging/wsdl", and use timg20 to represent the namespace of Imaging service 2.0, which is "http://www.onvif.org/ver20/imaging/wsdl". (Please note the red part marks the minor differences between namespaces.) An Imaging service command is called "GetOptions" (it's used to acquire the configuration options an imaging sensor supports), then this command in Imaging service 1.0 is written as timg10:GetOptions, while in Imaging service 2.0 it's written as timg20:GetOptions. Because of the differences in XML namespace, the two functionally identical commands becomes two entirely seperate commands. When developer is writing implementation code, he must write two copies of very similar code to support both versions.
In practice, the minor differences with many similar code could easily cause developers to make a lot of bugs.