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

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