Re: Another approach to supporting non-XML data

On Fri, Oct 5, 2012 at 12:32 AM, Toman, Vojtech <vojtech.toman@emc.com> wrote:
> I like the idea as it is simple and does not break/change too many things in the language. And, in a way, it extends on a principle that users are already used to - passing around URI references (typically "file:...") instead of forcing the non-XML data (base64-encoded, wrapped, ...) through the pipeline.
>
> I actually think if we changed the steps such as p:store, p:xsl-formatter etc. so that:
>
> - they return <c:data href="..."/>  instead of <c:result>...</c:result>
> - the "result" output port is primary

+1 to this!  The output port not being primary on p:store has caused
me problems.

>
> Having a standardized "binary" URI scheme may not be necessary, although it would probably be beneficial for interoperability. For instance, in our XProc processor we support "transient:..." URIs for storing content that is available during the lifetime of the pipeline.
>

I could see it being useful to construct transient URIs.  For example,
you could effective store a result to an transient URI and retrieve it
later.  That assumes you can guarantee ordering somehow.

> I also wonder how important streamability of non-XML data is.
>

I think that is a quality of implementation question.  Certainly if
you use p:http-request to retrieve a "large" binary, if the processing
of the entity body is deferred till it is consumed by another step,
you'd have some efficiency wins.  You would have to have done some
kind of static analysis to guarantee that the response would only be
used once.   Otherwise, you'd have to cache the binary stream for
possible re-use.

-- 
--Alex Milowski
"The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered."

Bertrand Russell in a footnote of Principles of Mathematics

Received on Saturday, 6 October 2012 15:58:03 UTC