RE: calling for xproc pain points, requested features, etc

The thought of using a uri resolver for such things reminds me of the
source provider facilities in Apache Cocoon. You just needed to invent a
scheme prefix of your own, associate that with a particular class, and
that class would return sources or inputstreams to whatever was
represented by the uri. Could be anything, even data from database..

I'm not saying we should have something like that in XProc, but it was
very powerful because it operated in such low level that it could be used
everywhere instantly, in existing components without the need to do extra.
Just refer to your scheme and that was it. Worked for writing as well..

Just wanted to mention it.. ;-)

Grtz

-----Oorspronkelijk bericht-----
Van: Michael Sokolov [mailto:sokolov@ifactory.com]
Verzonden: vrijdag 6 januari 2012 5:18
Aan: Imsieke, Gerrit, le-tex
CC: xproc-dev@w3.org
Onderwerp: Re: calling for xproc pain points, requested features, etc

On 1/5/2012 9:46 PM, Imsieke, Gerrit, le-tex wrote:
>
> Consider the case of an EPUB that contains XHTML files that link to
> CSS stylesheets. We have implemented a CSS parser in XSLT2. In order
> to make it work without too many annoying workarounds, we have to
> unpack the zip file first.
We found it convenient to write a URIResolver that pulls content out of
zip files; that way we can process all the epub pieces in place without
the need for temporary files.  It didn't present great difficulties,
although I may be missing something - we handled the spine and the rest,
but don't have a CSS parser - that sounds neat! But some ability to
enumerate the contents of the zip, (or to pull out the contents of a
"folder" from the zip - a kind of artificial construct) is a big help.

-Mike

Received on Friday, 6 January 2012 06:13:06 UTC