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