Re: own defined step and xml:base "inheritance"

Hi Romain,

Thanks a lot for your answer. It seems I'm in case "A", but maybe I got to
switch to case "B" (java implementation) to achieve what I want.

I tried to make the step's inner implementation to know that the string
passed is an URI, that's why I've add cx:type="xsd:anyURI" on the "caller"
and on the "reciever", but it seems not enough.
I tried your suggestions :

* resolve-uri :

  <igs:xslt href=“resolve-uri(xsl/step1.xsl)”/> => won't work because xproc
doesn't know AVT (Attributes Value Template)

  So I tried :

  <igs:xslt debugFileName="step1.xml">
     <p:with-option name="href" select="resolve-uri('xsl/step1.xsl
')"></p:with-option>
   </igs:xslt>

But I get an error : SEVERE: Pipeline failed: err:XC0011: Could not load
file: ... the file path is the resolve-uri from 'xsl/step1.xsl' to the path
where the xproc file is, not base on @xml:base neither @base-uri if I add
it.

* base-uri
<igs:xslt href=“xsl/step1.xsl” base-uri=“file:///D:/res/common/xsl/”/>
works fine as long as I'm loading the stylesheet like this in common.xpl :
<p:load name="load_stylesheet">
      <p:with-option name="href" select="resolve-uri($href,$base-uri)"/>
</p:load>

But that mean I would have to declare @base-uri on every <igs:xslt> and I
can't hertitate it from the markup, just like @xml:base would do.

The last solution I found is to load the stylesheet with a <p:document> as
an input port :

  <p:import href="_dev/src/igs/common.xpl"/>
  <p:pipeline type="igs:xml2ecf" psvi-required="false" xml:base="
file:///D:/res/common/xsl/">
      <igs:xslt>
         <p:input port="stylesheet"><p:document
href="xsl/step1.xsl"/></p:input>
      </igs:xslt>
  </p:pipeline>

and then in common.xpl doing :
<p:xslt>
        <p:input port="stylesheet">
          <!--<p:pipe port="result" step="load_stylesheet"/>-->
          <p:pipe port="stylesheet" step="current"/>
        </p:input>
        <p:input port="source">
            <p:pipe port="source" step="current"/>
        </p:input>
        <p:input port="parameters">
            <p:pipe port="parameters" step="current"/>
        </p:input>
</p:xslt>

It works fine : the xml:base attributes are "applied" and I can override
them if necessary.

So my profile.xpl file could now looks like this :

<p:import href="common.xpl"/>
<p:pipeline type="igs:xml2ecf" xml:base="file:///D:/res/common/xsl/">
    <igs:xslt><p:input port="stylesheet"><p:document
href="xsl/step1.xsl"/></p:input></igs:xslt>
    <igs:xslt><p:input port="stylesheet"><p:document
href="xsl/step2.xsl"/></p:input></igs:xslt>
    <igs:xslt xml:base="file:///C:/local/res/xsl/"><p:input
port="stylesheet"><p:document href="xsl/step3.xsl"/></p:input></igs:xslt>
    <igs:xslt><p:input port="stylesheet"><p:document
href="xsl/step4.xsl"/></p:input></igs:xslt>
    <igs:xslt><p:input port="stylesheet"><p:document href="xsl/step5.xsl"
xml:base="http://www.igs-cp.fr/net/res/xsl/"/></p:input></igs:xslt>
</p:pipeline>

This is a bit more verbose as the original plan :
<p:import href="common.xpl"/>
<p:pipeline type="igs:xml2ecf" xml:base="file:///D:/res/common/xsl/">
    <igs:xslt href="xsl/step1.xsl"/>
    <igs:xslt href="xsl/step2.xsl"/>
    <igs:xslt href="xsl/step3.xsl" xml:base="file:///C:/local/res/xsl"/>
    <igs:xslt href="xsl/step4.xsl"/>
    <igs:xslt href="xsl/step5.xsl" xml:base="
http://www.igs-cp.fr/net/res/xsl"/>
</p:pipeline>

But this is OK !

Thanks to all for helping, explaning and your patience, I can say my
problem is solved !

Cheers

Matthieu









2013/12/16 Romain Deltour <rdeltour@gmail.com>

> If I understand correctly I believe your goal below is not achievable if
> the step “igs:xslt” is implemented in XProc (i.e. if it is *not* a
> processor-specific step implemented in Java).
>
> I’ll try to explain why.
>
> A. if the step is implemented in XProc
>
> All the step knows is that it declares an option “href” in its signature,
> which is received as a string. The step’s inner implementation
> (“subpipeline") has absolutely no idea of the caller’s base URI.
> The step's inner implementation  may do whatever it wants with that
> string. It may identify the string as a relative URI and then resolve
> against something, but at this point the only base against which it can
> resolve it is the step’s document itself.
>
> The only ways that the step’s inner implementation may know about the
> caller URI are:
>
>   * make sure that only absolute URIs are passed to the href option (i.e.
> use the “resolve-uri()” function upfront when you call the step. In this
> case you would call the step like:
>
>               <igs:xslt href=“resolve-uri(xsl/step1.xsl)”/>
>
>   * pass the base URI as another option
>
>       <igs:xslt href=“xsl/step1.xsl” base-uri=“file:///D:/res/common/xsl/”
> />
>
>
> B. If the step is an atomic step, for instance implemented in Java
>
> The implementation will know the XML context where the step is called, so
> it will know the base URI of the caller. It can use it to post-process the
> step’s options, like resolving the href option.
>
> Hope this helps.
> Romain.
>
>
> On 16 déc. 2013, at 18:17, RICAUD-DUSSARGET Matthieu <
> matthieu.ricaud@igs-cp.fr> wrote:
>
> My goal is to make the first file (call "profile.xpl")  as simple as
> possible (see "the context" at
> http://markmail.org/thread/ih72ahgckiuejb4o).
>  For example :
>
> <p:import href="common.xpl"/>
> <p:pipeline type="igs:xml2ecf" xml:base="file:///D:/res/common/xsl/">
>     <igs:xslt href="xsl/step1.xsl"/>
>     <igs:xslt href="xsl/step2.xsl"/>
>     <igs:xslt href="xsl/step3.xsl" xml:base="file:///C:/local/res/xsl"/>
>     <igs:xslt href="xsl/step4.xsl"/>
>     <igs:xslt href="xsl/step5.xsl" xml:base="
> http://www.igs-cp.fr/net/res/xsl"/>
> </p:pipeline>
>
> As you see there is not only one xml:base to care, the user define the
> most usefull xml:base for his resssources and then can make exception when
> necessary.
>  I would have like the file to keep so simple as this sample but I guess
> this will be difficult.
>
>
>


-- 
Matthieu Ricaud-Dussarget
IGS-CP - Développeur XML
05 45 37 09 49

Received on Tuesday, 17 December 2013 11:05:40 UTC