Re: Getting from "Good Start" to "Great Solution” . . ?

Christopher.R.Ball <christopher.r.ball@gmail.com> writes:
> [An Open Letter]

Thanks for writing it!

>     I have wondered for some time if the xProc community has the
> will to take xProc from a "Good Start" to a "Great Solution” . . .
> from a “niche utility” of the XML elite, to a “fundamental tool” of
> the masses?

That would be nice. :-)

The focus of the XProc WG's exploration of a possible V.next is
improved usability.

>     In the case of xProc 1.x, it feels like there is an abundance of
> small accidental forms of complexity. While each instance of
> accidental complexity is seemingly trivial on its own, the
> cumulative effect is a significant barrier to entry. Thus in its
> current form, xProc feels like it could benefit from a book like
> Douglas Crockford's JavaScript: The Good Parts to weed out these
> unintuitive and idiosyncratic aspects.

Fair enough. I couldn't stand up and say with a straight face that
usability was the foremost concern on my mind during the design
of 1.0.

> "Un-intuitive Naming"
>
>     Getting off the ground with a new programming language is
> challenging and I credit the working group for crafting a good start
> to naming. But the semantics need to improve, it is critical that
> terms be expressive and distinct and avoid baggage from other
> domains. Java was well served in early adoption by borrowing
> terminology and syntax from C while feeling the freedom to form new
> constructs and mechanisms. Likewise, xProc should borrow concepts
> and semantics from xPath, XSLT, and the like. At present there is a
> blend of name and concept collision along with

I don't disagree, in principle, with the observation that our names
could be better, notwithstanding the fact that I am about to push back
on your specific suggestions :-)

>     For example:
>
>         • “view-port” as a step name is not consistent with naming
>           that clearly conceptually relates from numerous other programming
>           languages. A far more consistent and intuitive name would have been
>           “for-each-node” or “for-each-fragment” or “for-each-match”.

You don't think that would raise significant confusion with respect to
the existing p:for-each step?

>         • “identity” is essentially a “copy” and should be named as
>           such

Except for the fact that it *doesn't* make a copy, necessarily.

>         • “source” & “result” – as a port name for a pipelining
>           language which supports recursive structures this is borrowing from
>           the wrong paradigm and are overloaded terms as well. The terminology
>           could have been better borrowed from the father of pipelines, Petri
>           Nets or fundamental and expressive terminology such as inbound
>           content and outbound content.

So is your proposal explicitly to use "inbound" and "outbound" instead
of "source" and "result"?

> "How to Continue the Evolution"
>
>     The recipes could enable 4 critical pieces to the language's development:
>
>         1. What are the problems it is envisioned to solve
>         2. How does it solves those problems (and there may be more than one way)
>         3. What are the most important or most common use cases / stories
>         4. How succinctly, intuitively, and efficiently it solves them
>
>     While number 3 has a large subjective element, I think it is the
> most important and yet is absent from the current conversation.

The use cases and requirements document set out to provide some of
these stories.

>     A healthy discussion/debate of these recipes could lead to the
> evolution of a language. It would be a shame to see xProc languish
> as the niche tool of elite XML jocks rather than as a potential draw
> to XML itself. But that means a willingness to really look at xProc
> with a critical eye and a willingness to change what at first glance
> may seem embedded in concrete.

I'm willing, but probably have a hard time seeing the forest for the
trees. Suggestions, radical or otherwise, from fresh eyes would be
most welcome.

>     While I certainly do not have all the answers, I do hope I can
> stimulate the community and assist in evolving xProc to realize its
> full potential.

I hope so too!

                                        Be seeing you,
                                          norm

-- 
Norman Walsh
Lead Engineer
MarkLogic Corporation
Phone: +1 512 761 6676
www.marklogic.com