You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by "Craeg K. Strong" <cs...@arielpartners.com> on 2002/03/04 00:00:17 UTC
[PROPOSE] More candidates for Ant 1.5...
Hello:
I have not been monitoring ant-dev as closely these days,
so please let me know if any of this is redundant. In any event, I
believe the
following would be some really nice additions for a 1.5 release:
1) First off, is it true that there is already a general entity resolver
capability in ant? I saw mention of an XCatalog datatype. That is a good
start -- perhaps we could add the capability to point to a file in addition
to nested elements, the same way properties can be specified in line
or via a file.
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?
3) Integration with XSLTC. Precompiling XSLT stylesheets to Java
bytecode "translets"
apparently provides something on the order of a 600% performance
improvement.
The <style> task could be enhanced to optionally precompile the
stylesheets, such that
after the first time, each new transformation would be much faster.
4) Enhancements to <description> tag. Not sure how high a priority
this one is.
Until GUIs like antidote become more common, simple text is probably
good enough.
Once you have a GUI, it might be nice, however, to have HTML markup or
structured text
or some such in <description>.
Well, that is my 2cents worth. I hope to have some time to actually
work on this stuff in a few
weeks. My gut feeling is that 1.5 won't be released for another two
months or so, so that might actually
be ok timing? Anyway, I wanted to get some sense from the list as to
a) relative priorities of the
above, and b) implementation advice: it seems the code base has been
refactored a good bit, so my
knowledge is now out of date...
Thanks in advance,
--Craeg
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSE] More candidates for Ant 1.5...
Posted by "Craeg K. Strong" <cs...@arielpartners.com>.
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.
--Craeg
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSE] More candidates for Ant 1.5...
Posted by dIon Gillard <di...@multitask.com.au>.
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
http://adslgateway.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSE] More candidates for Ant 1.5...
Posted by "Craeg K. Strong" <cs...@arielpartners.com>.
(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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSE] More candidates for Ant 1.5...
Posted by dIon Gillard <di...@multitask.com.au>.
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
http://adslgateway.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSE] More candidates for Ant 1.5...
Posted by "Craeg K. Strong" <cs...@arielpartners.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [PROPOSE] More candidates for Ant 1.5...
Posted by dIon Gillard <di...@multitask.com.au>.
Craeg K. Strong wrote:
> Hello:
>
> I have not been monitoring ant-dev as closely these days,
> so please let me know if any of this is redundant. In any event, I
> believe the
> following would be some really nice additions for a 1.5 release:
>
> 1) First off, is it true that there is already a general entity resolver
> capability in ant? I saw mention of an XCatalog datatype. That is a
> good
> start -- perhaps we could add the capability to point to a file in
> addition
> to nested elements, the same way properties can be specified in line
> or via a file.
I submitted the xcatalog stuff over the weekend. The list of ids in a
file is not a bad idea, but not something I desperately need...feel free
to submit a patch, though :)
>
> 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.
Other tasks that could/need to be retrofitted with XCatalog are ejbjar
and XMLValidate.
> [snip]
>
> Thanks in advance,
>
> --Craeg
I've got no comment on the rest.
--
dIon Gillard, Multitask Consulting
http://adslgateway.multitask.com.au/developers
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>