ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craeg K. Strong" <>
Subject Re: [PROPOSE] More candidates for Ant 1.5...
Date Thu, 07 Mar 2002 17:35:26 GMT
dIon Gillard wrote:

> Craeg K. Strong wrote:
>> [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 
> 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? 

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.  


To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message