Re: XProc Usability (was Re: New to Xproc Question : conditionnal "output port" definition?)

> What struck me most after writing it is that it's not really much more
> compact than the XML syntax.

I had the same feeling, although it does save a few characters.

>  Jeni Tennison took up the challenge to
> produce a more natural compact syntax. I'm having trouble getting
> JavaCC to swallow it, but I'll get there eventually, I expect.

Interesting, please keep us posted!

BR,
Romain.

Le 12 oct. 11 à 16:29, Norman Walsh a écrit :

> Zearin <zearin@gonk.net> writes:
>> <opinion feedback="wanted" feedback-types="flames comments  
>> questions suggestions misc">
>>    The barrier of entry to XProc newcomers is needlessly high. I
>>    think of it sort of like W3C’s XSD spec: it’s capable of
>>    achieving powerful goals—but it bends over backwards so much to
>>    accommodate implementors that the end users spend all their time
>>    trying to learn all the “inconvenient corners” of XProc  
>> instead
>>    of making progress on their projects.
>
> Could you be more specific?
>
> In the case of the outputs-must-be-the-same rule, that's for logical
> consistency of the pipeline, not implementor convenience. We could
> have added a special rule for p:error, but that has costs too and it's
> not obvious to me that the benefits outweigh the costs.
>
>>    XProc was invented to fill a sorely-needed role for macroscopic
>>    XML processing—but just getting it to work is an obstacle that
>>    has often cost me more time than I would have spent using
>>    simpler tools. But I tried to force myself through it anyway,
>>    because I wanted to stick to as many official XML tools as
>>    possible.
>
> Simpler tools, or just different tools? Can you enumerate lessons
> learned along the way?
>
>>    *deep breath*
>>
>>    Going back to my earlier comparison: if XProc is like XSD, then
>>    tools like XMLSH are like Relax-NG. Both XMLSH and RNG (or RNC)
>>    solve the same goals as W3C specs, and they both do it with a
>>    very significantly lower learning curve.
>
> Would a non-XML syntax for XProc help?
>
> I have one. I presented it as a "PechaKucha" lightning talk at XML
> Summer School.
>
> XML Syntax:
>
> <p:pipeline xmlns:p="http://www.w3.org/ns/xproc"
>            version='1.0'>
> <p:serialization port="result"
>                 method="xhtml" indent="true"/>
>
> <p:xinclude/>
>
> <p:xslt>
>  <p:input port="stylesheet">
>    <p:document href="dbslides.xsl"/>
>  </p:input>
> </p:xslt>
>
> </p:pipeline>
>
> "Compact" syntax:
>
> pipeline {
>  serialization "result" with method="xhtml", indent="true"
>  xinclude
>  xslt {
>    input "stylesheet" {
>      document "dbslides.xsl"
>    }
>  }
> }
>
> What struck me most after writing it is that it's not really much more
> compact than the XML syntax. Jeni Tennison took up the challenge to
> produce a more natural compact syntax. I'm having trouble getting
> JavaCC to swallow it, but I'll get there eventually, I expect.
>
>>    <aside>
> [...]
>>        I don’t know what to make of this. …On the other hand, I
>>        have never written any script that generates XProc or XSL
>>        for me. (I wish I were that good! I envy devs that can do
>>        this.)
>
> I've certainly written stylesheets that produce stylesheets. And I'm
> one of the outliers who's unconvinced that moving from an XML
> pattern-based syntax to a string syntax for XPath (back way before
> XSLT 1.0 came out) was a good thing. Water under the bridge.
>
>>        What are the pros and cons of designing a language to work
>>        with XML using an XML syntax vs. a non-XML syntax?
>
> That's a good question. I'm toying with the idea of writing about it
> for XML Prague 2012. You know, in my copiuos free time.
>
>>    Of course, there is the XProcVNext page on the XProc wiki.
>>    There’s some very good ideas there. Has anyone else looked at it
>>    recently?
>>
>>    No?  Now’s a good time to start! ☺
>>
>>    Is there any official work (as in W3C) on improving XProc at the  
>> moment?
>
> No. The XProc WG is not chartered to do new work. We're going to talk
> informally about next steps at the upcoming f2f in CA. It's a bit of a
> chicken and egg problem. Trying to get the W3C Membership and our
> member companies to support work on V.next would be aided by greater
> adoption of V1.0.
>
>                                        Be seeing you,
>                                          norm
>
> --
> Norman Walsh
> Lead Engineer
> MarkLogic Corporation
> Phone: +1 413 624 6676
> www.marklogic.com

Received on Wednesday, 12 October 2011 15:32:23 UTC