- From: Innovimax SARL <innovimax@gmail.com>
- Date: Sun, 27 May 2007 16:47:04 +0200
- To: "Norman Walsh" <ndw@nwalsh.com>
- Cc: public-xml-processing-model-wg@w3.org
On 5/26/07, Norman Walsh <ndw@nwalsh.com> wrote: > / Innovimax SARL <innovimax@gmail.com> was heard to say: > | So when I look again to p:count, p:store and p:xsl-formatter, I see a > | different semantic for port !result > | > | Everywhere, the port !result is related to the input (say it has a > | content which is the input more or less deltas) > | except p:count, p:store and p:xsl-formatter > > Personally, I'm not bothered by the current semantics. > > | I'm proposing two things : > | > | 1) state the fact that we use !result in a consistent manner through > | the XProc spec > > I don't find the current use of the result port "inconsistent". > > For that matter, what would constitute consistent? If I pass a DocBook > document to an XSLT step and I get an HTML document out, how is that > consistent? It is consistent because it is the same content in another form (or format) > > | 2) change the signature of p:count and p:store > | 2.a) change the port named !result by another name and keep result if necessary > > I could live with this, though I don't feel it's necessary. > > | 2.b) OR introduce a new semantic, p:export-option, that simply makes available > | to the subsequent step the value of an option > | <p:count/> > | <!-- here $count has been exported as the value of count and !result > | reexport the input --> > > This would require the invention of some entirely new mechanism and > I'm strongly opposed. It is not really new It is strictly equivalent as today's <p:count name="count"/> <p:option name="$count" select="@value"> <p:pipe step="count" port="result" /> </p:option> and it has the advantage of pushing simple types data into options instead of XML files > > | I would also argue that p:tee would be no more needed if !result of > | p:store would make available the input > > I already concede that we don't need p:tee. Great > > But having the result of p:store be the same as its input seems > unnecessary. That's not mandatory in my proposal. I could leave with p:store having NO output at all > If you wanted the input, you could just read it from > wherever store reads it. Fine by me Mohamed -- Innovimax SARL Consulting, Training & XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 8 72 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 €
Received on Sunday, 27 May 2007 14:47:07 UTC