|
Generally well-thought concept, but bad implementation and examples. Version numbers are not appropriate for labeling capabilities. Each version always includes more that one capability, and requiring 2 versions to my mindset only leaves the option for the higher. Let me explain.
If you label capabilities based on versions, let's say 1 and 2, then the following
<require>
<version>1</version>
<version>2</version>
</require>
only leaves one choice available, namely that of version 2 --assuming requirements are ANDed, which I believe is a logical choice. ORing them wouldn't make much sense to me.
On the other hand is this:
* labeling version 1 as "v1"
* labeling version 2 as "v2"
* labeling new capability of v2 "packaging"
* labeling version 3 as "v3"
* labeling new capability of v3 "quantity"
If a processor could safely ignore the additions after version 1, then the message could be marked as
<require><capability>v1</capability></require>
If a processor must understand "packaging", but maybe not all other "v2" additions the message could be marked as
<require>
<capability>v1</capability>
<capability>packaging</capability>
</require>
If a processor must understand the complete set of additions of "v2" or "v3", then the message would be marked accordingly
<require><capability>v3</capability></require>
and only version 3 processors would be able to read it.
This approach requires much more well-though capability design, but allows more granular specification of requirements on the message level.
Regards,
Christos
|
Previous Message
