Eddie pointed out that if we ever intend to implement support for calling v1.x services (https://issues.apache.org/jira/browse/UIMA-125), it would be good idea *now* to add an operation that can be invoked on our Vinci services to have them report what "XCAS versions" they support. That way in v2.2 (or whatever) when we want to add support for calling v1.x services, we'll have a way of distinuighing v1.x services from v2.1 services.
So I plan to quickly add an operation getSupportedXCasVersions to our Vinci services. This could potentially respond with a list of versions that are supported. The client can then act appropriately to use one of the supported XCAS versions that the client also supports. I think these it's better to make these version numbers be different than the UIMA framework version number. It's possible that UIMA v3 will support both XCAS v2 and XCAS v3 (if we ever have such a thing), and we have no way of knowing that now so if the service just said it was UIMA v3 we'd have no idea if it was compatible with a v2 client. So currently our services would respond to this call with just a single version which I think should be "2". (Or maybe "2.0", but I don't really see a need for the .0, and maybe if we should use the minor version number for compatible changes, so if we invent XCAS v2.1 at some point that should be something that's readable by our current services?) These version numbers should also be in the XCASes themselves, eventually. Anyway, v1.x services would report an error when this call was made. That's how you know they don't support XCAS v2. However, this has the unfortunate effect of breaking compatibility with existing v2.0 services (at least for multi-sofa CASes), because existing v2.0 services also would report the same error as v1.x services. Maybe IBM could release a v2.0.3 that patches this, if there is a need. I don't see a better solution at the moment. Let me know (soon) if you have one. -Adam
