dIon Gillard wrote:
Craeg K. Strong wrote:
Given the XCatalog we've just finished, we could 'reuse' it here as well, and add a 'urn' nested element to it. How does that sound?[snip]
How about-- for example:
<style in = "foo.xml" out = "bar.html" style = "transform.xsl" uriresolver = "com.arielpartners.xml.Resolver"/>
where uriresolver is an optional attribute that specifies a class that implements the javax.xml.transform.URIResolver interface.
Of course, the class you provide would have to be on your path. We could always get more fancy, but
at least that would give us a "hook"
Thoughts
Excellent! I think that could work out very well. There are some interesting challenges, however:
URIResolvers can be simple maps from URNs to URLs or from public URLs to other (system) URLs or
what have you, but they might also be more sophisticated. In fact, they could algorithmically derive
one URL from another. I am not sure if that is legal for XML entity resolution? Maybe they are
restricted to simple mappings?
In any event, I can see sort of an evolutionary strategy, where URI Resolvers could be:
a) simple maps embedded directly in the ant build file, and/or
b) refer to external XMLCatalog files for the mappings, and/or
c) call out to a class that implements the URIResolver interface that could do all sorts of fancy stuff.
That way you only pay for the complexity that you need.
I am willing to help in whatever way I can.
--Craeg
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
