You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Adam Lally (JIRA)" <ui...@incubator.apache.org> on 2006/11/21 17:08:05 UTC
[jira] Created: (UIMA-50) Add version number to descriptors
Add version number to descriptors
---------------------------------
Key: UIMA-50
URL: http://issues.apache.org/jira/browse/UIMA-50
Project: UIMA
Issue Type: Improvement
Components: Core Java Framework
Reporter: Adam Lally
Priority: Minor
It has been suggested that our component descriptor XML files should include a version number, so that it would be possible to give more meaningful error messages in the case of a version mismatch. I'm not sure whether this should just be the framework version number, or a different "descriptor model version number" that might change less frequently.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (UIMA-50) Add version number to descriptors
Posted by "Adam Lally (JIRA)" <ui...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/UIMA-50?page=comments#action_12451757 ]
Adam Lally commented on UIMA-50:
--------------------------------
I think I basically agree with you, Marshall. My only concern is adding complexity by having too many different version numbers.
> Add version number to descriptors
> ---------------------------------
>
> Key: UIMA-50
> URL: http://issues.apache.org/jira/browse/UIMA-50
> Project: UIMA
> Issue Type: Improvement
> Components: Core Java Framework
> Reporter: Adam Lally
> Priority: Minor
>
> It has been suggested that our component descriptor XML files should include a version number, so that it would be possible to give more meaningful error messages in the case of a version mismatch. I'm not sure whether this should just be the framework version number, or a different "descriptor model version number" that might change less frequently.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (UIMA-50) Add version number to descriptors
Posted by "Tong Fin (JIRA)" <ui...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/UIMA-50?page=comments#action_12452536 ]
Tong Fin commented on UIMA-50:
------------------------------
I believe that having both versions (Framework and DTD/Schema) is useful for the following reason:
1) Tools will use Framework version to identify if the descriptors are appropriate for the Framework being used/targetting. If the tools don't have this info, we need a mapping from DTD/Schema version to Framework.
2) DTD/Schema version will be used when parsing/creating/validating the descriptor
> Add version number to descriptors
> ---------------------------------
>
> Key: UIMA-50
> URL: http://issues.apache.org/jira/browse/UIMA-50
> Project: UIMA
> Issue Type: Improvement
> Components: Core Java Framework
> Reporter: Adam Lally
> Priority: Minor
>
> It has been suggested that our component descriptor XML files should include a version number, so that it would be possible to give more meaningful error messages in the case of a version mismatch. I'm not sure whether this should just be the framework version number, or a different "descriptor model version number" that might change less frequently.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (UIMA-50) Add version number to descriptors
Posted by Marshall Schor <ms...@schor.com>.
+1 to all the comments about Jira vs email. I confess to not realizing
this was
a Jira comment :-[ , in the first place.
-Marshall
Adam Lally wrote:
> On 2/14/07, Thilo Goetz <tw...@gmx.de> wrote:
>> +1 on using Jira comments for this kind of discussion. I think anything
>> that has a bearing on the issue itself, the discussion or solution of
>> the issue, should be posted to Jira . Meta-comments, like "I'm going to
>> work on this tomorrow" should be posted to the list. That's my rule of
>> thumb, anyway.
>>
>
> OTOH, email seems like a better medium if you're going to really
> dig-in and have a detailed discussion about something.
>
> For me I think it's more about the timeframe. If an issue is actively
> being worked on, or about to be worked on, then I think it is fine to
> discuss details on uima-dev (and perhaps later a link to the email
> archives can be added to the JIRA issue). If work is not in progress
> (like UIMA-50) JIRA comments are better because email will be
> forgotten.
>
> -Adam
>
>
Re: [jira] Commented: (UIMA-50) Add version number to descriptors
Posted by Adam Lally <al...@alum.rpi.edu>.
On 2/14/07, Thilo Goetz <tw...@gmx.de> wrote:
> +1 on using Jira comments for this kind of discussion. I think anything
> that has a bearing on the issue itself, the discussion or solution of
> the issue, should be posted to Jira . Meta-comments, like "I'm going to
> work on this tomorrow" should be posted to the list. That's my rule of
> thumb, anyway.
>
OTOH, email seems like a better medium if you're going to really
dig-in and have a detailed discussion about something.
For me I think it's more about the timeframe. If an issue is actively
being worked on, or about to be worked on, then I think it is fine to
discuss details on uima-dev (and perhaps later a link to the email
archives can be added to the JIRA issue). If work is not in progress
(like UIMA-50) JIRA comments are better because email will be
forgotten.
-Adam
Re: [jira] Commented: (UIMA-50) Add version number to descriptors
Posted by Thilo Goetz <tw...@gmx.de>.
Adam Lally wrote:
<snip>
> A meta-comment: I'm not planning on working on this immediately, so
> it may be good to post these as JIRA comments or post a JIRA comment
> that links to this thread in the mail archives. Otherwise, if/when I
> get back to it will not remember what you said. (In fact the reason I
> posted this JIRA comment which was just a cut-and-paste of an old
> email, was so that I wouldn't forget what *I* had said. :)
>
> I wonder if there is some best-practice here, as to when it is better
> to use uima-dev and when it is better to post a JIRA comment?
>
> -Adam
+1 on using Jira comments for this kind of discussion. I think anything
that has a bearing on the issue itself, the discussion or solution of
the issue, should be posted to Jira . Meta-comments, like "I'm going to
work on this tomorrow" should be posted to the list. That's my rule of
thumb, anyway.
--Thilo
Re: [jira] Commented: (UIMA-50) Add version number to descriptors
Posted by Adam Lally <al...@alum.rpi.edu>.
On 2/14/07, Marshall Schor <ms...@schor.com> wrote:
> Adam Lally (JIRA) wrote:
> > [ https://issues.apache.org/jira/browse/UIMA-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473162 ]
> >
> > Adam Lally commented on UIMA-50:
> > --------------------------------
> >
> > Adding this comment, which was I sent in an email some time ago:
> >
> > 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?
> >
>
> I think the numbering scheme is fairly arbitrary. This might be
> something tied to the standards
> work at OASIS. See for instance, DocBook, which has schemas
> standardized at OASIS, with
> numbers like 4.5, with the "impl" on Sourceforge (the XSL
> transformations) being 1.72.0 etc.
>
> > 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?
>
> I don't think so. Instead of rejection, it should try and continue. In
> the case of a schema version that
> indicates a "later" scheme, it would be nice if we could do something
> similar to XSL.
>
> XSLT defines elements that let a writer write in a new schema, and
> have a "fallback", to be used if the framework processing this
> doesn't recognize the element.
>
> XSLT has a "Forwards Compatibility" mode (as well as backwards
> compatibility). In this mode, the framework can treat things it
> doesn't understand the same way it might treat things such as
> "vendor-extensions" (which we don't have any of, right now) it
> doesn't understand:
>
> * Report an error for elements it doesn't understand, unless
> there is some kind of fallback specification
> * Ignore attributes it doesn't understand
>
> I don't claim to have thought all this out carefully at this point -
> so just take this as an example of what might be do-able.
>
> > 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).
> >
>
> I would vote for not having this be an error.
> > 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.
> >
>
> +1
> > 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?)
> >
>
> Sounds good / promising.
>
> The Schema(s) seems to be something that is (are) a good candidate for
> standardization.
>
A meta-comment: I'm not planning on working on this immediately, so
it may be good to post these as JIRA comments or post a JIRA comment
that links to this thread in the mail archives. Otherwise, if/when I
get back to it will not remember what you said. (In fact the reason I
posted this JIRA comment which was just a cut-and-paste of an old
email, was so that I wouldn't forget what *I* had said. :)
I wonder if there is some best-practice here, as to when it is better
to use uima-dev and when it is better to post a JIRA comment?
-Adam
Re: [jira] Commented: (UIMA-50) Add version number to descriptors
Posted by Marshall Schor <ms...@schor.com>.
Adam Lally (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/UIMA-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473162 ]
>
> Adam Lally commented on UIMA-50:
> --------------------------------
>
> Adding this comment, which was I sent in an email some time ago:
>
> 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?
>
I think the numbering scheme is fairly arbitrary. This might be
something tied to the standards
work at OASIS. See for instance, DocBook, which has schemas
standardized at OASIS, with
numbers like 4.5, with the "impl" on Sourceforge (the XSL
transformations) being 1.72.0 etc.
> 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?
I don't think so. Instead of rejection, it should try and continue. In
the case of a schema version that
indicates a "later" scheme, it would be nice if we could do something
similar to XSL.
XSLT defines elements that let a writer write in a new schema, and
have a "fallback", to be used if the framework processing this
doesn't recognize the element.
XSLT has a "Forwards Compatibility" mode (as well as backwards
compatibility). In this mode, the framework can treat things it
doesn't understand the same way it might treat things such as
"vendor-extensions" (which we don't have any of, right now) it
doesn't understand:
* Report an error for elements it doesn't understand, unless
there is some kind of fallback specification
* Ignore attributes it doesn't understand
I don't claim to have thought all this out carefully at this point -
so just take this as an example of what might be do-able.
> 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).
>
I would vote for not having this be an error.
> 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.
>
+1
> 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?)
>
Sounds good / promising.
The Schema(s) seems to be something that is (are) a good candidate for
standardization.
-Marshall
[jira] Commented: (UIMA-50) Add version number to descriptors
Posted by "Adam Lally (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-50?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12473162 ]
Adam Lally commented on UIMA-50:
--------------------------------
Adding this comment, which was I sent in an email some time ago:
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?)
> Add version number to descriptors
> ---------------------------------
>
> Key: UIMA-50
> URL: https://issues.apache.org/jira/browse/UIMA-50
> Project: UIMA
> Issue Type: Improvement
> Components: Core Java Framework
> Reporter: Adam Lally
> Priority: Minor
>
> It has been suggested that our component descriptor XML files should include a version number, so that it would be possible to give more meaningful error messages in the case of a version mismatch. I'm not sure whether this should just be the framework version number, or a different "descriptor model version number" that might change less frequently.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-50) Add version number to descriptors
Posted by "Marshall Schor (JIRA)" <ui...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/UIMA-50?page=comments#action_12451691 ]
Marshall Schor commented on UIMA-50:
------------------------------------
Putting a version number on the XML is to indicate which version of the descriptor DTD/Schema is being used. This enables having the descriptor DTD/Schema evolve over time with better backward/forward compatibility operations.
I don't think this is the Framework version number. Are there are arguments for having that too (in addition)?
> Add version number to descriptors
> ---------------------------------
>
> Key: UIMA-50
> URL: http://issues.apache.org/jira/browse/UIMA-50
> Project: UIMA
> Issue Type: Improvement
> Components: Core Java Framework
> Reporter: Adam Lally
> Priority: Minor
>
> It has been suggested that our component descriptor XML files should include a version number, so that it would be possible to give more meaningful error messages in the case of a version mismatch. I'm not sure whether this should just be the framework version number, or a different "descriptor model version number" that might change less frequently.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira