W3C home > Mailing lists > Public > xproc-dev@w3.org > February 2011

Re: p:exec -- can it apply to only selected parts of input using a loop?

From: Jostein Austvik Jacobsen <josteinaj@gmail.com>
Date: Mon, 7 Feb 2011 22:27:57 +0100
Message-ID: <AANLkTikhb3hDuejYwwsdevPQ3CAfa-tHH8d_cPR03Vwp@mail.gmail.com>
To: Alex Muir <alex.g.muir@gmail.com>
Cc: Leif Warner <abimelech@gmail.com>, XProc Dev <xproc-dev@w3.org>
When comparing it to for-each loops in procedural languages, it's
interesting to note that the spec doesn't seem to say anything about the
order the subpipelines of the p:viewport and p:for-each steps are run in.
While what p:iteration-position() each subtree is assigned are AFAIK
determined from the XSLTMatchPattern, the actual execution of each subtree
could be done as separate threads/processes and/or in any order.

Usually this won't matter, unless for instance the subpipelines needs to
communicate with a web service or the file system.

Regards
Jostein

2011/2/7 Alex Muir <alex.g.muir@gmail.com>

> Yeah and the subpipeline lets you do anything within that operation that
> could affect other things not within the xml result file such as some
> http-request to another server to initiate an operation.
>
> I have been thinking of xml for document processing only these days however
> pipelines are used in industry to communicate results of some data analysis
> on data that just came into a company for example and could literally send a
> message about the data and transform it into some other information for
> example which is a ticket to say I have processed this input data and save
> that in the xml node with a copy of the input which is moved to database by
> another pipeline. So viewport now does sound more appropriate in that
> context given one is viewing some data and porting a bunch of information to
> other severs.. lol
>
> I may be it's more often about doing something with the data rather than
> say document standardization for example. Although both are possible domains
> of xproc. These days,, months,, I'm just standardizing data so have been
> thinking of the pipeline as a means to organize a series of xslt
> transformations and viewport is hardly a natural term in that context. In
> that context it's more like a p:doEdit ;)
>
> Can't please every newbie..
> Alex
>
>
>
> On Sun, Feb 6, 2011 at 10:09 PM, Leif Warner <abimelech@gmail.com> wrote:
>
>> I think of p:viewport as the counterpart to p:for-each that doesn't split
>> up the input into a sequence of documents.  I think of it like the "map"
>> function in most languages - apply an operation to a sequence but don't
>> modify the structure.
>>  The name was a big stumbling block for me as to what it's actually for
>> when I first got started.
>> I would prefer a name like "map" or at least something that more strongly
>> ties it to p:for-each.
>>
>> (I know languages like Ruby, Python, JavaScript, and Scala have both map
>> and foreach counterparts.  And then languages like Haskell, XQuery, and XSLT
>> don't differentiate between the two as they're functional/declarative
>> languages.)
>> -Leif Warner
>>
>> On Sat, Feb 5, 2011 at 4:09 AM, Alex Muir <alex.g.muir@gmail.com> wrote:
>>
>>> Sorry if I was a bit annoying on this posting but I found the discussion
>>> instructive and the emotion I was trying to convey from the keyboard was one
>>> of positive inquisitive criticism. I had some more thoughts on this which
>>> led to some observations.
>>>
>>> Jostein opened my eyes to the fact that viewport is more a for-each-match
>>> than a modify nodes.
>>>
>>> The thought came to mind that this common xslt pattern could be thought
>>> of as a viewport in some way.
>>>
>>> <xsl:template match="*">
>>>     <xsl:copy>
>>>       <xsl:copy-of select="@*"/>
>>>       <xsl:apply-templates/>
>>>     </xsl:copy>
>>>   </xsl:template>
>>>
>>> <xsl:template match="some/path">
>>>   ...
>>> </xsl:template>
>>>
>>>
>>> I studied more about the difference between for-each and viewport in the
>>> spec.
>>>
>>> I noted from the spec that one important difference is that for-each can
>>> apply to a "sequence of documents" and viewport applies to a "single
>>> document" both "applying its subpipeline to one or more subtrees".
>>>
>>> I had not yet seen an example applying for-each to a sequence of
>>> documents as it's input but would like to see one. Rather the examples I
>>> have seen are all applying a for-each to one input document like a directory
>>> list and say outputting a sequence of documents.
>>>
>>>
>>> I note the spec says when describing p:iteration-position "Both
>>> p:for-each and p:viewport process a sequence of documents."
>>>
>>> and that
>>>
>>> "Within a p:viewport, the p:iteration-position and p:iteration-size are
>>> taken from the sequence of documents that will be processed by the
>>> p:viewport. The total number of documents is the p:iteration-size; the
>>> ordinal value of the current document (the document appearing on the current
>>> port) is the p:iteration-position.?"
>>>
>>>
>>> So I'm wondering what is being conveyed by the descriptions regarding
>>> viewport as working with a sequence of documents or single documents. Is
>>> this a contradiction or is there a reason the spec speaks of sequences of
>>> documents and a single document with relation to viewport?
>>>
>>>
>>> Regards
>>> Alex
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Feb 2, 2011 at 1:14 PM, Jostein Austvik Jacobsen <
>>> josteinaj@gmail.com> wrote:
>>>
>>>> Also, viewports are useful for other stuff than just modifying a
>>>> document.
>>>>
>>>> For instance, what if you wanted to store all HTML elements as separate
>>>> HTML files but ignore all TEXT elements? in this case p:modifySubtree
>>>> and p:modifyNode wouldn't be meaningful.
>>>>
>>>> I look at p:viewport as a kind of advanced version of p:for-each. If it
>>>> had to be renamed, then maybe p:for-each-match ?
>>>>
>>>> Anyway, I like "p:viewport" - both the step and it's name :)
>>>>
>>>> Regards
>>>> p:viewport-fan
>>>>
>>>> 2011/2/2 <vojtech.toman@emc.com>
>>>>
>>>> > Vojtech,, although I understand your points fully they
>>>>> > speak to me that viewport is talking about something
>>>>> > other than xml documents.
>>>>>
>>>>> Yes, the original viewport definition(s) may be unrelated to XML, but
>>>>> that does not mean we cannot take existing concepts and apply them to XML,
>>>>> or to any other area.
>>>>>
>>>>> Regards,
>>>>> Viewport :)
>>>>>
>>>>>
>>>>> --
>>>>> Vojtech Toman
>>>>> Consultant Software Engineer
>>>>> EMC | Information Intelligence Group
>>>>> vojtech.toman@emc.com
>>>>> http://developer.emc.com/xmltech
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Alex
>>> -----
>>> Currently:
>>> Freelance Software Engineer 6+ yrs exp
>>>  <http://www.facebook.com/pages/Bafila/125611807494851>
>>> Previously:
>>> https://sites.google.com/a/utg.edu.gm/alex/
>>>
>>>
>>> A Bafila, is two rivers flowing together as one:
>>> http://www.facebook.com/pages/Bafila/125611807494851
>>>
>>> Working on something like <p:pipe cmd="w3m $input lt $output, errOutput
>>> $error"/>
>>>
>>>
>>
>
>
> --
> Alex
> -----
> Currently:
> Freelance Software Engineer 6+ yrs exp
>  <http://www.facebook.com/pages/Bafila/125611807494851>
> Previously:
> https://sites.google.com/a/utg.edu.gm/alex/
>
>
> A Bafila, is two rivers flowing together as one:
> http://www.facebook.com/pages/Bafila/125611807494851
>
>
>
>
Received on Monday, 7 February 2011 21:28:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 February 2011 21:28:52 GMT