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: <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
|