removing storing of unresolved idrefs in PageViewports

[Glen Mazza <gm...@apache.org>]

Team,

In the PSLM we are saving unresolved idref's (e.g., the 
"internal-destination" of an fo:basic-link, where we have not yet 
determined the PV that it refers to) with both the PageViewport and the 
AreaTreeHandler:

public void addUnresolvedArea(String id, Resolvable res) {
   // add to the page viewport so it can serialize
   curPV.addUnresolvedIDRef(id, res);
   // add unresolved to tree
   areaTreeHandler.addUnresolvedIDRef(id, curPV);
}

I am wondering if it is actually necessary for us to store the idref's 
in the PV for this serialization purpose--I would like to remove this.  
All resolution, AFAICT, is done from the idrefs stored with the ATH.  I 
don't think the idref's take any significant space--it would appear we 
could always keep this information "live" in ATH even if we were to 
off-load (and reload) pages to disk while processing.

Thanks,
Glen

Re: removing storing of unresolved idrefs in PageViewports

[Glen Mazza <gm...@apache.org>]

Andreas L. Delmelle wrote:

>A closer look at ATH and PV shows that the two above steps are:
>- add the unresolved area to the viewport
>   stored in the VP as a Map id->List
>   where the List contains references to the source
>   areas (the link's hotspot, the page-number-citation...)
>- add the unresolved area to the ATH
>   stored here as a Map id->List
>   where the List contains references to the pageVPs
>   that have an unresolved area with a given id
>
>Right now, it still seems quite sane to keep the distinction. In principle,
>the ATH only needs to know which VPs contain an unresolved area mapping to a
>certain id, where it is the VPs themselves that need the details about the
>areas...?
>
>  
>

OK, now I see the reason.  Yes, it makes sense to retain the distinction.

Thanks,
Glen

Re: removing storing of unresolved idrefs in PageViewports

[Glen Mazza <gm...@apache.org>]

Andreas L. Delmelle wrote:

>>public void addUnresolvedArea(String id, Resolvable res) {
>>   // add to the page viewport so it can serialize
>>   curPV.addUnresolvedIDRef(id, res);
>>   // add unresolved to tree
>>   areaTreeHandler.addUnresolvedIDRef(id, curPV);
>>}
>>
>>I am wondering if it is actually necessary for us to store the idref's
>>in the PV for this serialization purpose--
>>    
>>
>
>I'm not sure either...
>>>From this code-snippet, it looks like the actual Resolvable instance is
>stored with the viewport, while the ATH indeed only seems to store the
>'link' between the id and the current VP (the latter again as a Resolvable)
>
>A closer look at ATH and PV shows that the two above steps are:
>- add the unresolved area to the viewport
>   stored in the VP as a Map id->List
>   where the List contains references to the source
>   areas (the link's hotspot, the page-number-citation...)
>- add the unresolved area to the ATH
>   stored here as a Map id->List
>   where the List contains references to the pageVPs
>   that have an unresolved area with a given id
>
>  
>

OK, the comment in PSLM -- that the saving of the unresolvedIDRef in the 
PV is *purely* for serialization purposes--was misleading and 
incorrect.  That is what caused my confusion.  I updated the comment to 
clarify this.

Thanks,
Glen

RE: removing storing of unresolved idrefs in PageViewports

["Andreas L. Delmelle" <a_...@pandora.be>]

> -----Original Message-----
> From: Glen Mazza [mailto:gmazza@apache.org]
>

Hi,

> In the PSLM we are saving unresolved idref's (e.g., the
> "internal-destination" of an fo:basic-link, where we have not yet
> determined the PV that it refers to) with both the PageViewport and the
> AreaTreeHandler:
>
> public void addUnresolvedArea(String id, Resolvable res) {
>    // add to the page viewport so it can serialize
>    curPV.addUnresolvedIDRef(id, res);
>    // add unresolved to tree
>    areaTreeHandler.addUnresolvedIDRef(id, curPV);
> }
>
> I am wondering if it is actually necessary for us to store the idref's
> in the PV for this serialization purpose--

I'm not sure either...
>From this code-snippet, it looks like the actual Resolvable instance is
stored with the viewport, while the ATH indeed only seems to store the
'link' between the id and the current VP (the latter again as a Resolvable)

A closer look at ATH and PV shows that the two above steps are:
- add the unresolved area to the viewport
   stored in the VP as a Map id->List
   where the List contains references to the source
   areas (the link's hotspot, the page-number-citation...)
- add the unresolved area to the ATH
   stored here as a Map id->List
   where the List contains references to the pageVPs
   that have an unresolved area with a given id

Right now, it still seems quite sane to keep the distinction. In principle,
the ATH only needs to know which VPs contain an unresolved area mapping to a
certain id, where it is the VPs themselves that need the details about the
areas...?

No doubt it will work, but I don't know what the implications would be if we
were just to make it (which I think is your intention --correct?):

public void addUnresolvedArea(String id, Resolvable res) {
  // add unresolved to tree
  areaTreeHandler.addUnresolvedIDRef(id, curPV, res);
}

This would seem to mean a thorough revision of the whole
resolving-mechanism --where we inevitably will have to move some logic away
from the VP into the ATH, since the unresolved areas themselves will be
stored there, or at least, the ATH will have to pass their references back
to the VP somehow at some point.

> I would like to remove this.
> All resolution, AFAICT, is done from the idrefs stored with the ATH.

Yes and no. The resolution is ultimately co-ordinated from there, but if you
look closely, I think you will find that it actually 'triggers' resolution
at the level of the VP.
Where we can now have the ATH trigger resolution for all VPs that have
unresolved areas with a given id, and leave the details of this resolution
up to the VPs themselves, your proposal would lose the mapping between the
id's and the unresolved areas at VP level, so that the ATH would also have
to explicitly specify to the VP which areas are involved in the
resolution... where the shortest route would be to have ATH make the first
of the two method calls in its own addUnresolvedIDRef()... :-/

> I don't think the idref's take any significant space--it would appear we
> could always keep this information "live" in ATH even if we were to
> off-load (and reload) pages to disk while processing.

I'm not so sure... In a way, the minimum of required data already seems to
be kept live in the ATH.

Still, I'll have to dig a bit deeper first.


Cheers,

Andreas