[jdom-interest] Resolver announcement
jdom at tuis.net
Sun Mar 11 16:23:30 PDT 2012
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
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
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 ... ;-)
More information about the jdom-interest