Re: The first five minutes ... a thought experiment (long)

Its an interesting thought ...

reminds me of an analogy that has been percolating in my head

gradle (build tool for jvm) facades Ant and Maven and makes dependency
checking a lot simpler with simple Ivy approach.

Many people like gradle because;

I) its not got angle brackets

II) it supersedes Ant and Maven ... easy to use from gradle

III) it provides a programming language to enhance scripting

IV) modularity

When we get XProc v2 right, we will appeal to a broader set of
developer ... then we can easily address I) with some kind of
alternate encoding. I am playing with invisible XML and John
Snelsons's parser.xq right now ;)

For II) we need to identify common scenarios now (Ant scripts, bash
scripts, running xslt pipelined transformations) and address them in
vnext.

For III) and IV) I think allowing p:import of other language function
libraries is going to go some way to address that. We can define spec
in a way that would allow an implementator to import js libs ...
though how much detail the spec would contain to do this will be a
function of time/space. This way js can be authored in its own
preferred environment, instead of injection into markup, which just
gets ugly.

Experience suggests that v2 should be about usability and making it
easy to run easy pipelines; I think we should steer clear of higher
order abstractions ... though now is also a good time to capture for
v3 and things like custom compound steps could be defined there.

J




On 18 February 2014 10:33, Jostein Austvik Jacobsen <josteinaj@gmail.com> wrote:
> I can't help thinking about Robin Berjons session at the end of xmlprague
> about how HTML has been and will continue to successfully evolve and improve
> itself. HTML has JavaScript which allows developers to extend HTML, and then
> the extensions which proves useful and popular are standardized in future
> HTML versions. XProc does not have such a powerful way of creating
> extensions. I won't argue for JavaScript support in XProc, but I think it
> might be nice to have something more powerful than "just" being able to
> define custom atomic steps. Custom compound steps would be neat (but I
> realize it's probably not going to happen in v2). Maybe even some form of
> higher order functions(/steps). I haven't been thinking too thoroughly about
> this but there are limits to what one can do with custom atomic steps.
>
>
> Jostein
>
>
> On 17 February 2014 17:21, David Cramer <david@thingbag.net> wrote:
>>
>> On 02/17/2014 07:40 AM, James Fuller wrote:
>> > Many, many people repeated to me that XProc does poorly in the first
>> > five minutes, in fact, it takes several sessions before basic concepts
>> > crystallize. Many people give up at this stage but those that make it
>> > through, turn into hard core XProc users, as they have run up and over
>> > the learning curve.
>>
>> Likewise, for many users the xproc pipeline is something you get working
>> and leave alone for months. By the time you need to make a change to it,
>> you've forgotten the concepts and face the difficult "first five minutes
>> (hours?)" problem again.
>>
>> There's a common trade-off between "making easy thing easy" and "making
>> hard things possible". XProc indeed came down firmly on the "make hard
>> things possible" side of that trade-off at the expense of making easy
>> things easy.
>>
>> Perhaps some user stories/epics would help?
>>
>> As the maintainer of an xml publishing tool chain, I would like to
>> replace my kludgy Ant or make tool chain with XProc.
>>
>> Then focus on what makes each story hard.
>>
>> I have to say though that once you have it working, it's great!
>>
>> Regards,
>> David
>>
>>
>

Received on Tuesday, 18 February 2014 09:46:49 UTC