- From: Jostein Austvik Jacobsen <josteinaj@gmail.com>
- Date: Mon, 7 Feb 2011 22:27:57 +0100
- To: Alex Muir <alex.g.muir@gmail.com>
- Cc: Leif Warner <abimelech@gmail.com>, XProc Dev <xproc-dev@w3.org>
- Message-ID: <AANLkTikhb3hDuejYwwsdevPQ3CAfa-tHH8d_cPR03Vwp@mail.gmail.com>
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 UTC