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 Wed, 06 Mar 2002 20:34:59 GMT
Craeg K. Strong wrote:

> dIon Gillard wrote:
>> Craeg K. Strong wrote:
>>> 2) URIResolver for <style> task.  This would allow for things like 
>>> resolving
>>> URNs in XML documents.  This is incredibly useful for doing content 
>>> management,
>>> where you have lots of little document fragments that refer to each 
>>> other.  By using
>>> URNs, you can avoid hardcoding URLs that might change.  I am not sure
>>> whether this is best done as an optional extension to the <style> 
>>> task or as a datatype
>>> like XCatalog above.  Are there other tasks that could use this 
>>> capability?
>> I tested XCatalog against docbooks's DTD, since it uses a whole heap 
>> of relative entities in it's DTD.
>> This works well. What happens is you specify the URL in a single 
>> place, and use relative processing to handle them.
>> What sort of situation would need something other than entity 
>> resolution like this? Give me an example, and I'll see if the 
>> XCatalog stuff will help. 
> Here's an example:
> Imagine an XML document where you are describing the services offered 
> by your consulting practice :-)
> ....
> <P>
>    Ariel has the experience you need to jump start your standards 
> initiatives... blah blah...
>   In fact, our corporate mission is  <InlineInclude 
> uri="urn:arielpartners:content/public/library/df-mission.xml" 
> element="Block"/>
>   and we specialize in...
> </P>
> <Include 
> uri="urn:arielpartners:content/public/topics/offerings/services/p-consulting-practice-areas.xml"

> idref="Mentoring"/>
> <P>
>   more boring stuff ....
> </P> 

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.

> .....
> Here we have an inline fragment included inside a paragraph (the 
> corporate mission), and another paragraph
> that is included by grabbing a piece of another XML document (where 
> the fragment is identified by its ID).
> In order to use URNs above instead of the URLs everyone is familiar 
> with, I must install a URIResolver in my
> XSLT processor.

I thought URIResolvers were only used in xsl:import, xsl:include and 
document() calls in XSL?

> Why would I want to do such a thing?   
> Imagine the situation where you want the above to work:
> a) using ANT to drive an XSLT processor for a set of XML documents 
> contained in the file system (in CVS, for example) 

I'd use an entity.

> b) using Cocoon and Apache to drive a website where the XML sources 
> are actually stored inside a native XML database
> (Xindice, for example)
> c) Using a publishing environment like Zope where the XML content is 
> stored inside their object oriented database (ZODB).
> ....this is also across operating systems and for multiple clients.
> Rather than forcing a guarantee that the URL space remain the same in 
> all of the above situations, we "punt"
> and use URNs.    For each system (a,b,c) above, we maintain a URN -> 
> URL mapping database.  The URIResolver
> looks up the URN in the database and returns a URL appropriate to the 
> system we are using.  It "just works" ;-) 

Can you explain the "URL space remain the same" bit? If your entities 
have public Ids, you can specify completely separate URLs/locations for 
them in XCatalog.

> Of course, you could also use a URIResolver to look up URLs and 
> translate them to other URLs.  For example,
> you could have long-lived "standard" URLs that got translated to file 
> based versions (file:/c:/foo/bar) or whatnot. 

I don't get how you can do this in the current XSL spec. AFAIK, 
URIResolvers aren't used for translating tags like <Include> etc....Can 
you help me on that?

> I hope the above explanation is sufficient.  We have found 
> URIResolvers to be an incredibly useful way to add
> flexibility to our XML-based document processing.   Therefore I 
> believe adding a URIResolver facility to ant for <style>
> would be valuable, as we, among others, are using ant to statically 
> generate our HTML documents from XML.
> 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? 

I'm at a loss....I'm obviously missing something. Can you help?

> --Craeg

dIon Gillard, Multitask Consulting

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

View raw message