RE: result-document -- why does XProc care?

Hi Alex,

I think you are overlooking the fact that anything produced with
xsl:result-document doesn't get written to disk directly within XProc, but
is added to the secondary output sequence.

The current version of XProc doesn't account for non-XML data, but
XMLCalabash can cope with it reasonably well. Also, there is work in
progress to extend XProc in this area. Vojtech gave a nice presentation on
that topic at this year's XMLPrague conference:

Kind regards,

> -----Oorspronkelijk bericht-----
> Van: alyx []
> Verzonden: maandag 25 juni 2012 20:51
> Aan:
> Onderwerp: xsl:result-document -- why does XProc care?
> Good morning,
> So i'm writing an XRX webapp; wanting to be as standardsy as reasonably
> practical i decide to look at XProc for my build system -- and promptly
> face-first into the XD0001 bug^H^H^Herror upon trying to write HTML5.
> But before i wander over to see what Ant's been up to in the
half-a-decade since
> i've looked at it, i was wondering if anyone would be willing to explain
for a
> newbie the rationale behind that design decision.  If my XSLT2 transform
> produces as its primary output some nice xml -- or, as in my case, a
> Result Code 0 Everything's Cool WOO HOO -- to feed to the next step in
> pipeline if any, it's not immediately obvious to me why it's any of
> business if various xsl:result-document tags want to emit HTML5, or
> Dothraki, or pseudorandom gibberish.  I understand that, according to
> "non-XML documents are considered out-of-scope", but this seems like a
> (unnecessarily?) severe restriction upon its usefulness.
> (If i've missed a solution more elegant than the p:exec hackery i've
seen here,
> like if Calabash has a -chill flag or something, i'd also be happy to
hear it.)
> TIA, --alex.

Received on Tuesday, 26 June 2012 19:47:06 UTC