- From: Innovimax SARL <innovimax@gmail.com>
- Date: Wed, 26 Mar 2008 01:04:44 +0100
- To: "Norman Walsh" <ndw@nwalsh.com>
- Cc: public-xml-processing-model-wg@w3.org
- Message-ID: <546c6c1c0803251704g5fa29a82t98656d0c136494ac@mail.gmail.com>
Ok digging through I find some problems I see at first glance : It is said [[ The p:documentation<http://www.w3.org/XML/XProc/docs/langspec.html#p.documentation>element is not shown, but it is allowed anywhere. ]] but it is explicitely shown in the production of sub-pipeline Please remove it from there, it is confusing ----- Please do the same for p:pipeinfo (I mean when the FIXME will be filled) ----- One point I'm doing most of the time is documenting an input, and I want, if I remove the input, that the documentation will be considerate as no more accurate I propose for that purpose, to add to p:documentation an new attribute @refid which should refer to the value of an @xml:id attribute which provide the ability to properly document pipeline and to have a security in case, I suppress the element I was documenting (then the @refid would point to nothing) which could be given as a warning by an XProc processor in a interoperable way ----- Ok let's me try to arrive to the end of the path, I sketched subpipeline = (p:variable)*,(p:for-each |p:viewport | p:choose | p:group | p:try | p:*atomic* | *pfx:user-pipeline* )* (note that I remove p:pipeinfo and p:documentation since they can appear everywhere) If we say that the context of evaluation of p:variable is composed of the option that are declared before and all but the step of the siblings output port Mohamed On Thu, Mar 20, 2008 at 5:29 PM, Norman Walsh <ndw@nwalsh.com> wrote: > / Innovimax SARL <innovimax@gmail.com> was heard to say: > | instead of this > | > | subpipeline = (p:for-each > | |p:viewport | > | p:choose |p:group > | |p:try |p:*atomic* > | |*pfx:user-pipeline* | > | p:documentation|p:pipeinfo|p:variable)* > | > | can we try > | > | subpipeline = (p:variable|p:documentation|p:pipeinfo)*,(p:for-each > | |p:viewport | > | p:choose |p:group > | |p:try |p:*atomic* > | |*pfx:user-pipeline* | > | p:documentation|p:pipeinfo)* > > I don't think that would be sufficient. You could still say: > > <p:variable name="data" select="//p[1]"> > <p:pipe port="result" step="fw"/> > </p:variable> > > <p:xslt name="one"> > <p:input port="source" .../> > <p:input port="stylesheet" .../> > <p:with-param name="data" select="$data"/> > </p:xslt> > > <p:xslt name="fw"> > <p:input port="stylesheet" .../> > </p:xslt> > > which is horribly circular. I think the simplest solution is to say > that it is a static error if the xpath context of a p:variable refers > to any step that is among its siblings. > > Saying that the xpath context of a p:variable is always an empty > document strikes me as too limiting. > > Be seeing you, > norm > > -- > Norman Walsh | You must not think me necessarily > http://nwalsh.com/ | foolish because I am facetious, nor > | will I consider you necessarily wise > | because you are grave.--Sydney Smith > -- Innovimax SARL Consulting, Training & XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 9 52 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 €
Received on Wednesday, 26 March 2008 00:05:26 UTC