Re: Another approach to supporting non-XML data

Actually, I am not advocating generating data URIs for binary streams.
That is possible but I do not think it would be advisable.  Instead, that
should be an additional step or option for the edge cases where that would
be useful.

--Alex Milowski (via phone)
On Oct 4, 2012 1:34 PM, "James Fuller" <jim@webcomposite.com> wrote:

> On Thu, Oct 4, 2012 at 8:18 PM, Alex Milowski <alex@milowski.com> wrote:
> > An extension to this idea is that we can consider the XML instance
> > that refers to the binary data stream as a descriptor for transient
> > references (e.g. an open binary data stream).  We could use such "in
> > memory" and "in process" references for other things in the future.
> > The design pattern is that we pass around an XML instance that
> > contains the "keys" (typically URIs) that steps can use to access
> > these non-XML or hard to encode resources.
> >
> > Of course, how the implementation of the step does this depends on the
> > XProc implementation's API and so the actual URI dereferencing is
> > implementation defined.  If you serialize the XML, you'd just have a
> > funny looking URI in the XML that isn't resolvable by other tools or
> > after the pipeline has finished.
>
>
> I presume you are referencing http://tools.ietf.org/html/rfc2397
>
> be real nice if we could somehow gzip base64 somehow automagically
>
> interesting line of thought I will noodling over the next few days.
>
> J
>