[ 
https://issues.apache.org/jira/browse/UIMA-5536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marshall Schor updated UIMA-5536:
---------------------------------
    Description: 
The select API attempts to combine some of uimaFIT's capability for iterating.  
The design included a configuration choice "positionUsesType".  This was 
implemented incorrectly for some cases, and it seems it would be hard to fix.  
This Jira suggests removing it altogether.

What it does: It affects two bits of iterator operation:
# moveTo(fs) - move to the leftmost item that "matches" fs
# for bounded iterators: skip the item which is "equal" to the bound.

Details: The "matches" in 1) is based on the comparator for the index.  For 
Annotation indexes, this includes the typePriority.  However, the select API 
framework by default doesn't use type priorities (can be configured though). 
This means, if the underlying iterator is using type priorities, then doing a 
moveTo on it will move to a spot which might not be the "left-most" when type 
priorities are not used.  The correction for this has two flavors: depending on 
the setting of positionUsesType.  If not specified, the correction worked, and 
moved to the left-most same-begin-end-ignoring-type.  If specified, the 
correction was ignoring this, and a fix would need to scan in both directions 
to find the right type.  Although this could be done, it's complex.  And I 
think this is designing beyond a real need.  

Use 2 is for skipping the bounding annotation when iterating (if it is in the 
index).  The normal mode for skipping is to skip only the item if it is == 
identical to the bounding annotation.  But (for UIMA v2 bounded iterator 
compatibility) a mode where the compare is done using the Annotation Comparator 
is provided.  The positionUsesType would narrow this equal test by also 
requiring that the types match.  I think this is unnecessarily complex, since I 
think most uses will be using the == style.

So I propose to remove positionUsesType from the implementation / documentation.

  was:
The select API attempts to combine some of uimaFIT's capability for iterating.  
The design included a configuration choice "positionUsesType".  This was 
implemented incorrectly for some cases, and it seems it would be hard to fix.  
This Jira suggests removing it altogether.

What it does: It affects two bits of iterator operation:
# moveTo(fs) - move to the leftmost item that "matches" fs
# for bounded iterators: skip the item which is "equal" to the bound.

Details: The "matches" in 1) is based on the comparator for the index.  For 
Annotation indexes, this includes the typePriority.  However, the select API 
framework by default doesn't use type priorities (can be configured though). 
This means, if the underlying iterator is using type priorities, then doing a 
moveTo on it will move to a spot which might not be the "left-most" when type 
priorities are not used.  The correction for this has two flavors: depending on 
the setting of positionUsesType.  If not specified, the correction worked, and 
moved to the left-most same-begin-end-ignorming-type.  If specified, the 
correction was ignorning this, and a fix would need to scan in both directions 
to find the right type.  Although this could be done, it's complex.  And I 
think this is designing beyond a real need.  

Use 2 is for skipping the bounding annotation when iterating (if it is in the 
index).  The normal mode for skipping is to skip only the item if it is == 
identical to the bounding annotation.  But (for UIMA v2 bounded iterator 
compatibility) a mode where the compare is done using the Annotation Comparator 
is provided.  The positionUsesType would narrow this equal test by also 
requiring that the types match.  I think this is unnecessarily complex, since I 
think most uses will be using the == style.

So I propose to remove positionUsesType from the implementation / documentation.


> uv3 remove positionUsesType from select api
> -------------------------------------------
>
>                 Key: UIMA-5536
>                 URL: https://issues.apache.org/jira/browse/UIMA-5536
>             Project: UIMA
>          Issue Type: Bug
>    Affects Versions: 3.0.0SDK-alpha02
>            Reporter: Marshall Schor
>            Assignee: Marshall Schor
>             Fix For: 3.0.0SDK-beta
>
>
> The select API attempts to combine some of uimaFIT's capability for 
> iterating.  The design included a configuration choice "positionUsesType".  
> This was implemented incorrectly for some cases, and it seems it would be 
> hard to fix.  This Jira suggests removing it altogether.
> What it does: It affects two bits of iterator operation:
> # moveTo(fs) - move to the leftmost item that "matches" fs
> # for bounded iterators: skip the item which is "equal" to the bound.
> Details: The "matches" in 1) is based on the comparator for the index.  For 
> Annotation indexes, this includes the typePriority.  However, the select API 
> framework by default doesn't use type priorities (can be configured though). 
> This means, if the underlying iterator is using type priorities, then doing a 
> moveTo on it will move to a spot which might not be the "left-most" when type 
> priorities are not used.  The correction for this has two flavors: depending 
> on the setting of positionUsesType.  If not specified, the correction worked, 
> and moved to the left-most same-begin-end-ignoring-type.  If specified, the 
> correction was ignoring this, and a fix would need to scan in both directions 
> to find the right type.  Although this could be done, it's complex.  And I 
> think this is designing beyond a real need.  
> Use 2 is for skipping the bounding annotation when iterating (if it is in the 
> index).  The normal mode for skipping is to skip only the item if it is == 
> identical to the bounding annotation.  But (for UIMA v2 bounded iterator 
> compatibility) a mode where the compare is done using the Annotation 
> Comparator is provided.  The positionUsesType would narrow this equal test by 
> also requiring that the types match.  I think this is unnecessarily complex, 
> since I think most uses will be using the == style.
> So I propose to remove positionUsesType from the implementation / 
> documentation.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to