ant-dev mailing list archives

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

> [snip]
>> Where is <Include> coming from? Shouldn't this be an Entity, rather 
>> than an <Include> or <InlineInclude> tag? If you used an entity, and

>> gave it a public ID, you could easily use the new XCatalog stuff. 
> Sorry-- I left out a few steps.   <Include> and <InlineInclude> are 
> elements we have defined where the
> passed in URI gets called like so:  <xsl:apply-templates 
> select="document($passed-in-uri)/(passed-in-Xpath)"/>
> We are using the document() function, and that is how the URI Resolver 
> gets called.   The reason we don't use
> entities is that we usually don't want the _entire_ document.   We 
> like the flexibility of being able to include
> only a chunk, selected via XPath and/or XPointer.
> Otherwise, however, the principles are quite similar.   An XMLCatalog 
> is a URI map, plus the EntityResolver has some
> sort of fall-back lookup mechanism, right?  (it has been a while since 
> I looked at the details of catalogs) 

Gotcha. Makes perfect sense now.

> Yes.  In fact, you can use URNs in XMLCatalogs as well, can't you?   
> As I said, it is a very similar
> sort of facility.  That is why I am trying to figure out a way of 
> leveraging the design you have done
> for URIResolvers.... 

Yip, reasonably easily done. You could make XCatalog implement 
URIResolver as well, and then 'fix' the other tasks.

> [snip]

> Does the above help? 

Sure does.

> [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?

dIon Gillard, Multitask Consulting

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

View raw message