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 Wed, 06 Mar 2002 04:21:17 GMT
(see comments embedded below)

dIon Gillard wrote:

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

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)

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

yes

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

Unless you wanted to apply an XPath "filter" first, correct?

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

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

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

Does the above help?

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



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