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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

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

James Fuller-2
--

Todays WG meeting discussed the vagaries of explicitly defining port connections.

A number of proposals was floated to try and make life easier for the author. I thought I would
send through some informal emails to give an initial airing of each of the ideas percolating.

One syntax proposal which struck a chord with the WG, was an idea proposed by Henry S. Thompson,
to make it much easier (in the general use case) to define connection flow.

The idea is a new 'from' attribte would be defined on a step.

<p:pipeline>
  <p:identity name="mystep"/>
  <p:wrap-sequence .../>
  <p:count from="mystep"/>
</p:pipeline>

In this example, the 'from' attribute defines a connection from 'mystep' default readable port (eg. primary
output port of the p:identity 'mystep') to the p:count primary input port.

Which is semantically equivalent to the following pipeline.

<p:pipeline>
  <p:identity name="mystep"/>
  <p:wrap-sequence .../>
  <p:count>
    <p:input port="source">
      <p:pipe step="mystep" port="result"/>
    </p:input>
</p:pipeline>

While this simplification does not provide a broad range of new behaviour its a concise start towards making the
general use case easier and leverages existing port machinery already in place.

Obviously, there are still details to work out for the concrete proposal.

I am sure there are lots of room for variation and we want to hear your comments; though I am personally keen
to avoid ratholing on syntax, that is simplicity of use and alignment with current vnext will trump over complexity
or breadth of new behavior.

thx, Jim Fuller

ps- big thanks to Romain Deltour, his original email[1] which helped motivate action on this

[1] http://lists.w3.org/Archives/Public/public-xml-processing-model-comments/2014Feb/0001.html









Reply | Threaded
Open this post in threaded view
|

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

Florent Georges-5
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/

Reply | Threaded
Open this post in threaded view
|

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

James Fuller-2
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.

J


On 26 November 2014 at 19:59, Florent Georges <[hidden email]> 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/

Reply | Threaded
Open this post in threaded view
|

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

Imsieke, Gerrit, le-tex

On 26.11.2014 20:13, 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 like result@mystep, too, and I think we can shortcut even further. We
have a significant number of steps where an input port connects to
multiple output ports.

In a typical project, I found 35 out of 443 input connections and 2 out
of 171 output declarations that had multiple p:pipe children.

I don’t see what keeps us from turning the multiple pipes into
space-separated port@step tokens within a @from attribute:

<p:input port="meta">
   <p:pipe port="result" step="select-edition-meta"/>
   <p:pipe port="result" step="meta"/>
</p:input>

<p:input port="meta" from="result@select-edition-meta result@meta"/>

<p:output port="report" sequence="true">
   <p:pipe port="report" step="test-suite"/>
   <p:pipe port="report" step="regular-ebooks-iteration"/>
</p:output>

<p:output port="report" from="report@test-suite
report@regular-ebooks-iteration"/>

with a tacit sequence="true" if there are multiple tokens in @from or if
there are multiple p:pipe children. (?)

Gerrit

Reply | Threaded
Open this post in threaded view
|

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

Florent Georges-5
On 26 November 2014 at 21:58, Imsieke, Gerrit, le-tex wrote:

> I don’t see what keeps us from turning the multiple pipes into
> space-separated port@step tokens within a @from attribute:

  Sounds like a good generalization to me.

--
Florent Georges
http://fgeorges.org/
http://h2oconsulting.be/

Reply | Threaded
Open this post in threaded view
|

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

James Fuller-3
In reply to this post by Imsieke, Gerrit, le-tex
thx Gerrit, 

defining multiples in the 'from' attribute to represent multiple p:pipe seems like a win as well.

keep the thoughtful comments coming ... I do appreciate both yours and Florent eye for scope, your suggestions are also perfect in that respect (eg. the reality of how much change we can propose at this stage).

next step is a more formal description to WG and see if we can't get this drafted into spec language.

J


On Wed, Nov 26, 2014 at 9:58 PM, Imsieke, Gerrit, le-tex <[hidden email]> wrote:

On 26.11.2014 20:13, 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 like result@mystep, too, and I think we can shortcut even further. We have a significant number of steps where an input port connects to multiple output ports.

In a typical project, I found 35 out of 443 input connections and 2 out of 171 output declarations that had multiple p:pipe children.

I don’t see what keeps us from turning the multiple pipes into space-separated port@step tokens within a @from attribute:

<p:input port="meta">
  <p:pipe port="result" step="select-edition-meta"/>
  <p:pipe port="result" step="meta"/>
</p:input>

<p:input port="meta" from="result@select-edition-meta result@meta"/>

<p:output port="report" sequence="true">
  <p:pipe port="report" step="test-suite"/>
  <p:pipe port="report" step="regular-ebooks-iteration"/>
</p:output>

<p:output port="report" from="report@test-suite report@regular-ebooks-iteration"/>

with a tacit sequence="true" if there are multiple tokens in @from or if there are multiple p:pipe children. (?)

Gerrit


Reply | Threaded
Open this post in threaded view
|

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

Romain Deltour
+1 on Henry's proposal and Florent's and Gerrit's generalizations.

Thanks all!
Romain.

Le 27 nov. 2014 à 08:51, James Fuller a écrit :

thx Gerrit, 

defining multiples in the 'from' attribute to represent multiple p:pipe seems like a win as well.

keep the thoughtful comments coming ... I do appreciate both yours and Florent eye for scope, your suggestions are also perfect in that respect (eg. the reality of how much change we can propose at this stage).

next step is a more formal description to WG and see if we can't get this drafted into spec language.

J


On Wed, Nov 26, 2014 at 9:58 PM, Imsieke, Gerrit, le-tex <[hidden email]> wrote:

On 26.11.2014 20:13, 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 like result@mystep, too, and I think we can shortcut even further. We have a significant number of steps where an input port connects to multiple output ports.

In a typical project, I found 35 out of 443 input connections and 2 out of 171 output declarations that had multiple p:pipe children.

I don’t see what keeps us from turning the multiple pipes into space-separated port@step tokens within a @from attribute:

<p:input port="meta">
  <p:pipe port="result" step="select-edition-meta"/>
  <p:pipe port="result" step="meta"/>
</p:input>

<p:input port="meta" from="result@select-edition-meta result@meta"/>

<p:output port="report" sequence="true">
  <p:pipe port="report" step="test-suite"/>
  <p:pipe port="report" step="regular-ebooks-iteration"/>
</p:output>

<p:output port="report" from="report@test-suite report@regular-ebooks-iteration"/>

with a tacit sequence="true" if there are multiple tokens in @from or if there are multiple p:pipe children. (?)

Gerrit



Reply | Threaded
Open this post in threaded view
|

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

Paul Tyson
In reply to this post by James Fuller-2
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 <[hidden email]> 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/
>



Reply | Threaded
Open this post in threaded view
|

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

James Fuller-2
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 <[hidden email]> 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 <[hidden email]> 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/
>>
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

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

Florent Georges-5
On 1 December 2014 at 08:47, James Fuller wrote:

  Hi,

> 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.

  I probably missed something, but I did not get this one.  What
exactly do you refer to by "micro syntax"?  Why is from="port@step"
adoption unlikely?

  I thought the WG was looking at syntax simplification, and this one
looks like a very good one, and a rather easy one to define, as it is
mainly syntactic sugar, isn't it?

  Regards,

--
Florent Georges
http://fgeorges.org/
http://h2oconsulting.be/

Reply | Threaded
Open this post in threaded view
|

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

James Fuller-2
Hello Florent,

To summarise;

* @from attribute taking a step name (which denotes input from primary
output port)  seems to have broad support. This @from attribute can
live on the step as well as probably a p:input.

* enumerating multiple step names (as Gerrit proposed) seems non controversial

* some kind of way to address ports other then default primary output
seems like a useful optimisation, but (as Paul mentions) it is a kind
of departure, lets just wait and see where WG discussions bring us.

So while first and second points seem likely to get through WG, I am
less confident about getting agreement on a scheme (micro syntax) for
addressing ports/step ... as I said I like your suggestion and will
present to WG for consideration (along with alternates). Thanks for
being patient.

J


On 1 December 2014 at 10:56, Florent Georges <[hidden email]> wrote:

> On 1 December 2014 at 08:47, James Fuller wrote:
>
>   Hi,
>
>> 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.
>
>   I probably missed something, but I did not get this one.  What
> exactly do you refer to by "micro syntax"?  Why is from="port@step"
> adoption unlikely?
>
>   I thought the WG was looking at syntax simplification, and this one
> looks like a very good one, and a rather easy one to define, as it is
> mainly syntactic sugar, isn't it?
>
>   Regards,
>
> --
> Florent Georges
> http://fgeorges.org/
> http://h2oconsulting.be/

Reply | Threaded
Open this post in threaded view
|

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

Florent Georges-5
  Thanks Jim.  And no, I am not in a hurry :-)  Just a couple of points:

    - your 2d and 3d points are equally a "departure from using XML
structure to represent any single one info"; point 2 is using a
space-separated list of tokens in a string, instead of using a
repeatable element, whilst point 3 is using a special character to
separate both parts of a string as a pair of strings

    - there is already a syntax using exclusively XML structure to
represent information, and this is exactly what the syntax
simplification is looking at: providing an alternative to the verbose
XML syntax

  This is a perma-thread about XML data modelling.  The best example
of which, I believe, is the following question.  Is 2015-01-01 a
legitimate data type, or should it rather be
<date><year>2015</year><month>1</month><day>1</day></date>?

  As we have the XML structure approach already, offering an
alternative would just be listening to all people having been asking
for a simplification, for years.  That some people will not use it
should not prevent the simplification to happen.  If we were talking
about stopping developing the XML structured version, or reverting it
back, I could understand those concerns, but I think they are quite
irrelevant when discussing an alternative.

  Regards,

--
Florent Georges
http://fgeorges.org/
http://h2oconsulting.be/


On 1 December 2014 at 11:10, James Fuller wrote:

> Hello Florent,
>
> To summarise;
>
> * @from attribute taking a step name (which denotes input from primary
> output port)  seems to have broad support. This @from attribute can
> live on the step as well as probably a p:input.
>
> * enumerating multiple step names (as Gerrit proposed) seems non controversial
>
> * some kind of way to address ports other then default primary output
> seems like a useful optimisation, but (as Paul mentions) it is a kind
> of departure, lets just wait and see where WG discussions bring us.
>
> So while first and second points seem likely to get through WG, I am
> less confident about getting agreement on a scheme (micro syntax) for
> addressing ports/step ... as I said I like your suggestion and will
> present to WG for consideration (along with alternates). Thanks for
> being patient.
>
> J
>
>
> On 1 December 2014 at 10:56, Florent Georges <[hidden email]> wrote:
>> On 1 December 2014 at 08:47, James Fuller wrote:
>>
>>   Hi,
>>
>>> 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.
>>
>>   I probably missed something, but I did not get this one.  What
>> exactly do you refer to by "micro syntax"?  Why is from="port@step"
>> adoption unlikely?
>>
>>   I thought the WG was looking at syntax simplification, and this one
>> looks like a very good one, and a rather easy one to define, as it is
>> mainly syntactic sugar, isn't it?
>>
>>   Regards,
>>
>> --
>> Florent Georges
>> http://fgeorges.org/
>> http://h2oconsulting.be/

Reply | Threaded
Open this post in threaded view
|

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

Imsieke, Gerrit, le-tex
Jim,

I fully agree with Florent. In a previous message, you wrote that
connecting to non-primary ports has happened more frequently in practice
than the XProc 1.0 WG anticipated.

While the existing syntactic shortcuts have proven to be useful in
linear pipelines, there is demand for a more compact notation in cases
that still suffer from excessive verbosity. Connecting to a single
non-primary port (your contested third item) happens more frequently
than connecting to multiple ports (second item). If we want to cater to
current and future users’ demand, let’s go all the way and have all
three connection shortcuts:

– A from attribute for holding reference tokens to the outputs of other
steps;
– Where References to multiple ports are space separated;
– The ability to refer to a certain non-primary port of another step in
such a reference token.
I don’t care whether these tokens are formed like step(#port)? or like
(port@)?step.

As Florent said, it’s almost syntactic sugar. There is a bijection
between the short and the long form, not by lexical transformation of
one form into the other though – some pipeline analysis wrt primary
ports will be necessary.

In my view there is no need to engage in philosophical discussions
whether we have ID/IDREF relationships when we refer to ports of steps.
The tuple of port name and step name has to be unique within a step
declaration; attaching a single ID (@xml:id) to this is purely optional.
Please note, however, that in contrast to a given @xml:id value, a given
tuple of step/port names may occur more than once in a single XML file.
Consider p:library as an example for this.

Furthermore, there is no need to doubt whether the short form is still
XML. Of course it is. What we are suggesting is not a textual form, like
rnc is to rng. In order to prove that point, I’ll be happy to provide
XSLT 2 stylesheets that convert short form XML into long form XML and
vice versa, without resorting to unparsed-text() (only with resorting to
tokenize() or xsl:analyze-string).

Take this as a heavily invested user’s 2 ct.

Gerrit


On 01.12.2014 11:44, Florent Georges wrote:

>    Thanks Jim.  And no, I am not in a hurry :-)  Just a couple of points:
>
>      - your 2d and 3d points are equally a "departure from using XML
> structure to represent any single one info"; point 2 is using a
> space-separated list of tokens in a string, instead of using a
> repeatable element, whilst point 3 is using a special character to
> separate both parts of a string as a pair of strings
>
>      - there is already a syntax using exclusively XML structure to
> represent information, and this is exactly what the syntax
> simplification is looking at: providing an alternative to the verbose
> XML syntax
>
>    This is a perma-thread about XML data modelling.  The best example
> of which, I believe, is the following question.  Is 2015-01-01 a
> legitimate data type, or should it rather be
> <date><year>2015</year><month>1</month><day>1</day></date>?
>
>    As we have the XML structure approach already, offering an
> alternative would just be listening to all people having been asking
> for a simplification, for years.  That some people will not use it
> should not prevent the simplification to happen.  If we were talking
> about stopping developing the XML structured version, or reverting it
> back, I could understand those concerns, but I think they are quite
> irrelevant when discussing an alternative.
>
>    Regards,
>

--
Gerrit Imsieke
Geschäftsführer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany
Phone +49 341 355356 110, Fax +49 341 355356 510
[hidden email], http://www.le-tex.de

Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930

Geschäftsführer: Gerrit Imsieke, Svea Jelonek,
Thomas Schmidt, Dr. Reinhard Vöckler

Reply | Threaded
Open this post in threaded view
|

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

James Fuller-2
Hello Gerrit/Florent,

thanks for the ammo/data points, these will be very useful when I
present them to WG.

thx once again, J



On 1 December 2014 at 14:08, Imsieke, Gerrit, le-tex
<[hidden email]> wrote:

> Jim,
>
> I fully agree with Florent. In a previous message, you wrote that connecting
> to non-primary ports has happened more frequently in practice than the XProc
> 1.0 WG anticipated.
>
> While the existing syntactic shortcuts have proven to be useful in linear
> pipelines, there is demand for a more compact notation in cases that still
> suffer from excessive verbosity. Connecting to a single non-primary port
> (your contested third item) happens more frequently than connecting to
> multiple ports (second item). If we want to cater to current and future
> users’ demand, let’s go all the way and have all three connection shortcuts:
>
> – A from attribute for holding reference tokens to the outputs of other
> steps;
> – Where References to multiple ports are space separated;
> – The ability to refer to a certain non-primary port of another step in such
> a reference token.
> I don’t care whether these tokens are formed like step(#port)? or like
> (port@)?step.
>
> As Florent said, it’s almost syntactic sugar. There is a bijection between
> the short and the long form, not by lexical transformation of one form into
> the other though – some pipeline analysis wrt primary ports will be
> necessary.
>
> In my view there is no need to engage in philosophical discussions whether
> we have ID/IDREF relationships when we refer to ports of steps. The tuple of
> port name and step name has to be unique within a step declaration;
> attaching a single ID (@xml:id) to this is purely optional. Please note,
> however, that in contrast to a given @xml:id value, a given tuple of
> step/port names may occur more than once in a single XML file. Consider
> p:library as an example for this.
>
> Furthermore, there is no need to doubt whether the short form is still XML.
> Of course it is. What we are suggesting is not a textual form, like rnc is
> to rng. In order to prove that point, I’ll be happy to provide XSLT 2
> stylesheets that convert short form XML into long form XML and vice versa,
> without resorting to unparsed-text() (only with resorting to tokenize() or
> xsl:analyze-string).
>
> Take this as a heavily invested user’s 2 ct.
>
> Gerrit
>
>
> On 01.12.2014 11:44, Florent Georges wrote:
>>
>>    Thanks Jim.  And no, I am not in a hurry :-)  Just a couple of points:
>>
>>      - your 2d and 3d points are equally a "departure from using XML
>> structure to represent any single one info"; point 2 is using a
>> space-separated list of tokens in a string, instead of using a
>> repeatable element, whilst point 3 is using a special character to
>> separate both parts of a string as a pair of strings
>>
>>      - there is already a syntax using exclusively XML structure to
>> represent information, and this is exactly what the syntax
>> simplification is looking at: providing an alternative to the verbose
>> XML syntax
>>
>>    This is a perma-thread about XML data modelling.  The best example
>> of which, I believe, is the following question.  Is 2015-01-01 a
>> legitimate data type, or should it rather be
>> <date><year>2015</year><month>1</month><day>1</day></date>?
>>
>>    As we have the XML structure approach already, offering an
>> alternative would just be listening to all people having been asking
>> for a simplification, for years.  That some people will not use it
>> should not prevent the simplification to happen.  If we were talking
>> about stopping developing the XML structured version, or reverting it
>> back, I could understand those concerns, but I think they are quite
>> irrelevant when discussing an alternative.
>>
>>    Regards,
>>
>
> --
> Gerrit Imsieke
> Geschäftsführer / Managing Director
> le-tex publishing services GmbH
> Weissenfelser Str. 84, 04229 Leipzig, Germany
> Phone +49 341 355356 110, Fax +49 341 355356 510
> [hidden email], http://www.le-tex.de
>
> Registergericht / Commercial Register: Amtsgericht Leipzig
> Registernummer / Registration Number: HRB 24930
>
> Geschäftsführer: Gerrit Imsieke, Svea Jelonek,
> Thomas Schmidt, Dr. Reinhard Vöckler
>