[jdom-interest] Resolver announcement

[Rolf Lear]

On 11/03/2012 6:32 PM, Michael Kay wrote:
> In Saxon 9.4 I have addressed this problem by including a copy of the
> most common resources within the Saxon JAR file, and ensuring that when
> Saxon itself allocates the XMLReader, it uses an EntityResolver that
> grabs these local copies of resources when available. But Saxon isn't
> architecturally the right place for the solution, any more than JDOM is.
>
> I like the idea of a caching resolver: except that surely, the best way
> to offer this to the world is as an implementation of XMLReader that
> wraps an underlying XMLReader with a caching entity resolver. Then
> anyone who picks up this XMLReader implementation will automatically get
> the caching behaviour - even if they implement their own EntityResolver
> on top.
>
> But I think a variant of the caching resolver that only uses a
> pre-initialized cache containing the common W3C files, and doesn't
> attempt any dynamic caching, might be even more useful, because it would
> avoid needing access to writable filestore, and the synchronization and
> permissions issues that this introduces.
>
> Such a beast could easily be carved out of the existing Saxon code and
> turned into a freestanding component.
>
> Michael Kay
> Saxonica
>

I had considered that having a 'commonly used' repository of files would 
be an option, but that is very, very close to being a 'catalog', and 
that is solved. The problem I have run in to (often), is the 
availability of the resource data... when you need it.... and I have 
found that more now with JDOM maintenance.

I think the 'opportunity' for improvement is not in making a new web 
catalog, but in making an updatable 'catalog'. Existing catalog systems 
are not thread-safe for update, and that is the exact functionality I 
think is needed.

As for how the 'cache' is presented, I think that it will be a case of 
'wrapping' it in any number of ways to be useful... but, at the lowest 
level, it is just an EntityResolver, so I intended to start with that.

One 'novel' idea I have is that the cache is fully 'zippable', and it 
would be relatively trivial to zip up the cache, and unzip it in anothe 
location, and 'seed' a system.... and, perhaps I can make a 'zip' of the 
entire w3c.org resources.... which is what would be very useful... I 
have asked w3c for a complete 'catalog' of their resources, and there is 
none available....

Similarly, it would be relatively trivial to converts the cache in to a 
'catalog' that disregards the 'expires' time for these resources.

Specifically for the XMLReader suggestion, I think the proposed solution 
I have is specific enough to be out-of-shape with anything out there... 
for a start, it only resolves http(s) resources....

It needs to be a 'small' part of a bigger system.

I think the idea I have at the moment is to see how this functionality 
could fit in with other systems.... From what I can tell, there is no 
available system that does a local 'dynamic' cache of web-based 
resources. I think that is the 'gap' that needs to be solved....

Obviously, I could be completely wrong about that ... ;-)

Rolf