(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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
