On 1/18/07, Marshall Schor <[EMAIL PROTECTED]> wrote:
There has been some discussion about adding something to the UIMA XML
descriptors that
would indicate the "version" of the XML Descriptor - to allow for better
future change
management.
Was this ever done? Should this be a 2.1 item? Probably would be
"cleaner" to
introduce it as part of 2.x official releases...
It was not done. It's in JIRA: https://issues.apache.org/jira/browse/UIMA-50.
But what exactly should we do? We better decide in a hurry if this is
to get into 2.1.
I can add a schemaVersion=xxx attribue to our component descriptors.
What should xxx be? Is there any relation to the framework version,
or is it completely different? I think we agreed it's not the exact
same thing as the framework version number (v2.2 could potentially use
the same schemaVersion as 2.1, or not, we don't really know until we
get there). If it's completely different, how do we decide on the
numbering scheme to use?
Also what effect does this have on the actual beahvior of the
framework. Should the descriptor parsing check the version number and
immediately reject any descriptor with schemaVersion > xxx? It some
ways it seems like the current "unknown element" errors are superior -
at least that tells you what exactly about your descriptor is not
supported in the framework version you are using, so you might have
some hope of fixing it.
Also this might end up rejecting descriptors that would actually parse
fine, if for example the newer schemaVersion introduced new optional
elements (e.g., <flowController> in an aggregate), but those elements
were not used in the descriptor currently being parsed).
So maybe it is best not to actually have the version number have any
effect on processing, but just be there so that someday we could use
it. A future UIMA SDK version might make a change to part of the
schema but still want to provide support for older descriptors, and
could try to use the schemaVersion element to affect how it processed
that particular part of the descriptor.
Also maybe if a parse exception occurs we could include the schema
mismatch as part of the error message, in addition to the precise
reason for the parse exception. (Maybe I could catch
InvalidXMLExceptions at the top-level of the parse and wrap them in
another InvalidXMLException whose message states that there was a
schemaVersion incompatibility?)
-Adam
