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

Yes, as Geert said this seems to be in discussion for XProc VNext, see this wiki page:
http://www.w3.org/wiki/Architecture#What_flows.3F

Romain.

On 26 juin 2012, at 21:46, Geert Josten wrote:

> 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 20:00:46 UTC