ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craeg K. Strong" <cstr...@arielpartners.com>
Subject Re: [PROPOSE] More candidates for Ant 1.5...
Date Tue, 05 Mar 2002 21:20:39 GMT
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>
.....

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.

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)

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" ;-)

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

--Craeg



--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message