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:
http://www.xmlprague.cz/2012/sessions.html#XProc-Beyond-application/xml

Kind regards,
Geert

> -----Oorspronkelijk bericht-----
> Van: alyx [mailto:alyxtmp-netbeans@yahoo.com]
> Verzonden: maandag 25 juni 2012 20:51
> Aan: xproc-dev@w3.org
> 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
run
> 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
simple
> Result Code 0 Everything's Cool WOO HOO -- to feed to the next step in
the
> pipeline if any, it's not immediately obvious to me why it's any of
XProc's
> business if various xsl:result-document tags want to emit HTML5, or
unparsed
> Dothraki, or pseudorandom gibberish.  I understand that, according to
XProc,
> "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