W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > October 2012

Re: Another approach to supporting non-XML data

From: Alex Milowski <alex@milowski.com>
Date: Thu, 4 Oct 2012 13:53:08 -0700
Message-ID: <CABp3FNKNPeuiaEwCe1Ear_LnM5ZAyRWfpong-muchoPPWbA2qQ@mail.gmail.com>
To: James Fuller <jim@webcomposite.com>, XProc WG <public-xml-processing-model-wg@w3.org>
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
>
Received on Thursday, 4 October 2012 20:53:36 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 4 October 2012 20:53:37 GMT