Re: ease of use proposal - adding 'from' attribute to step to define connection

yes, I agree with your observations about the 'micro' syntax and its
likely that getting that aspect (in result@mystep form) through the WG
will be difficult and less likely.

What is very clear (to me), is that xproc vnext *needs* to try some
radical changes to be easier to use (in the first five minutes ->
first few days scenarios) throughout iterative development.

We need to be able to say to folks when we release xproc vnext is 'hey
we know that xproc v1 was a bit difficult to use, but come back and
take another look' and deliver on that ... we have only one chance at
that.

At the WG, I am sure we will discuss all the variations of how to
address a step's ports, eg result@mystep ... it maybe that something
like an implied id like #mystep.result is easier to accept.

thx for the comments, J



On 30 November 2014 at 23:08, Paul Tyson <phtyson@sbcglobal.net> wrote:
> On Wed, 2014-11-26 at 20:13 +0100, James Fuller wrote:
>> Its an interesting thought  (FWIW- originally I also was toying with
>> things like mystep#result so its nice to here confirmation from a 2nd
>> pair of eyes).
>>
>> I also like result@mystep ... and from my pov still fits in with the
>> scope of change being discussed.
>
> I'm not entirely unsympathetic to shortcuts such as this (I'd rather
> they be handled by tools). But defining a particular microsyntax for
> such things seems to me a significant (and unnecessary) departure from
> traditional XML idiom.
>
> Especially so, considering that the venerable XML id/idref idiom exactly
> meets the need here (for defining connections), except for the
> well-intentioned but problematic notion of default ports, which need no
> explicit instance representation.
>
> Nevertheless, please consider defining an xlink representation of
> connections as a generalization of the current connection syntax. This
> which would allow in simple cases an id/idref type connection between
> ports, and perhaps through some simple conventions the connection of
> multiple inputs and outputs through default ports.
>
> Regards,
> --Paul
>
>
>> J
>>
>>
>> On 26 November 2014 at 19:59, Florent Georges <fgeorges@fgeorges.org> wrote:
>> > On 26 November 2014 at 18:01, Jim Fuller wrote:
>> >
>> >   Hi,
>> >
>> >>   <p:identity name="mystep"/>
>> >>   <p:wrap-sequence .../>
>> >>   <p:count from="mystep"/>
>> >
>> >> [...]
>> >> Which is semantically equivalent to the following pipeline.
>> >
>> >>   <p:identity name="mystep"/>
>> >>   <p:wrap-sequence .../>
>> >>   <p:count>
>> >>     <p:input port="source">
>> >>       <p:pipe step="mystep" port="result"/>
>> >>     </p:input>
>> >
>> >   I like the idea.  But it is limited to primary ports.  What about
>> > something like the following, allowing to give the port as well
>> > (indeed still using the primary port if not explicit):
>> >
>> >     <p:count from="result@mystep"/>
>> >
>> >   Because both names are NCNames, we could use "mystep:result" as
>> > well, but it would then look too much like a QName, and people would
>> > wonder why "mystep" prefix is not declared.  I liked "mystep.result"
>> > but "." is a legitimate character in an NCName. I like "mystep→result"
>> > as well, but I do not think the IT world is  ready yet for that in
>> > 2015.
>> >
>> >   I think that from="result@mystep" reads quite easy in plain English.
>> >
>> >   Regards,
>> >
>> > --
>> > Florent Georges
>> > http://fgeorges.org/
>> > http://h2oconsulting.be/
>>
>
>
>
>

Received on Monday, 1 December 2014 07:48:15 UTC