XProc LC Disposition of Comments

On 25 February 2010 13:56, Norman Walsh wrote:

>  If the try-namespaces option is “true”, the processor should attempt
>  to dereference the namespace URI to locate schema documents. If the
>  option is “false”, the processor should not dereference namespace
>  URIs.

> Suppose the attempt fails. I assume that that does not raise an error,
> it's simply ignored.

  Sounds reasonable.  But in the first time, I'd say that's rather
strange to try to dereference  target namespace URIs.  Resolving URIs
is implementation-defined, and furthermore namespace URIs should not
be treated as dereferencable I think (what if you have a URN instead
of a URL, btw?)

  Regards,

-- 
Florent Georges
http://www.fgeorges.org/

I think the idea is that that:

- @status-only = true means that the only thing returned by the step
is a <c:response /> with the status code.
- @detailed = false means that no <c:response/> is returned.  Instead
it returns either the XML document from the response only, or the text
response inside a <c:body /> or <c:multipart />.

So if you set them that way, you have a contradiction.

-James

On Wed, Feb 24, 2010 at 1:35 PM, Norman Walsh <ndw@nwalsh.com> wrote:
> Why is this an error?
>
>  <c:request method="..." status-only="true" detailed="false"/>
>
>> It is a dynamic error (err:XC0004) if the status-only attribute has
>> the value true and the detailed attribute does not have the value
>> true.
>
>                                        Be seeing you,
>                                          norm
>
> --
> Norman Walsh <ndw@nwalsh.com> | The lasting pleasures of contact with
> http://nwalsh.com/            | the natural world are not reserved for
>                              | scientists but are available to anyone
>                              | who will place himself under the
>                              | influence of the earth, sea and sky and
>                              | their amazing life.--Rachel Carson
>

There is dynamic error err:XD0001: "It is a dynamic error if a non-XML
resource is produced on a step output or arrives on a step input." This
really captures the essence of XProc, where only XML is allowed to flow
between the steps in the pipeline.

 

You are asking for a specific feature for the p:xslt step, but I am
afraid the same new rules for wrapping the non-XML results would have to
apply to any steps (standard or extension) that may produce non-XML
output. And that would be quite a substantial change to the spec at this
stage of the game, I think.

 

Regards,

Vojtech

 

--

Vojtech Toman

Principal Software Engineer

EMC Corporation

toman_vojtech@emc.com

http://developer.emc.com/xmltech

 

 

 

From: xproc-dev-request@w3.org [mailto:xproc-dev-request@w3.org] On
Behalf Of Bruce Chapman
Sent: Friday, February 19, 2010 4:08 AM
To: public-xml-processing-model-comments@w3.org
Cc: xproc-dev@w3.org
Subject: xslt step with stylesheet having <xsl:output method="text" />

 

Hello,

 

The spec is unclear as to what should happen when a <p:xslt> step has a
stylesheet requesting text output method. (<xsl:output method="text" />)

 

While you would not normally want to do this, I was wishing to use an
existing stylesheet with text output method and follow it with a
<p:store> and I had hoped it would just do the right thing.

 

Calabash didn't like that - and probably rightly so according to the
spec. 

 

There is no mention of this case in 7.1.31 p:xslt
<http://www.w3.org/TR/xproc/#c.xslt>  or in 2.2.2 Non-XML Documents
<http://www.w3.org/TR/xproc/#binary>  and I would expect that it should.

 

There are a couple of ways of addressing this issue IMHO.

 

1.	7.1.31 p:xslt specification could say that implementations must
wrap any method=text output document(s) in <c:data> (preferred)
2.	7.1.31 p:xslt specification could specify that stylesheets with
an output method of text are not permitted. (present situation made
explicit)
3.	some convoluted gymnastics in the spec (section 2.2.2?) to
permit non xml output from p:xslt provided it only feeds into  p:store
step(s)  (- a harder way of achieving the same as option 1  J  )

 

And yes I solved my problem by changing the stylesheet to have XML
output method, and wrapped the text in a <c:data> document element. But
that now means I have two versions of the stylesheet, one for use in
Xproc, and a separate one for use in our proprietary pipeline tool which
uses text pipes. - hopefully I can decommission the latter before the
duplication bites me where it hurts.

 

Bruce

 

On 19 February 2010 04:07, Bruce Chapman wrote:

> And yes I solved my problem by changing the stylesheet to have
> XML output method, and wrapped the text in a <c:data> document
> element. But that now means I have two versions of the
> stylesheet, one for use in Xproc, and a separate one for use in
> our proprietary pipeline tool which uses text pipes.

  You can always use a one-line stylesheet (ok, a "few-lines"
stylesheet) that imports your original stylesheet and wraps its
output in, say, a data element:

    <p:input port="stylesheet">
       <p:inline>
          <xsl:stylesheet version="2.0">
             <xsl:import href="your original import uri"/>
             <xsl:template match="/">
                <data>
                   <xsl:apply-imports/>
                </data>
             </xsl:template>
          </xsl:stylesheet>
       </p:inline>
    </p:input>

  Regards,

-- 
Florent Georges
http://www.fgeorges.org/

Bruce Chapman <bruce.chapman@nec.co.nz> writes:

> There are a couple of ways of addressing this issue IMHO.

As Vojtech observed, this is explicitly covered by err:XD0001.
The WG is not inclined to extend the p:xslt step at this time.
Please let us know if you're unsatisfied by this resolution.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Politics is the art of looking for
http://nwalsh.com/            | trouble, finding it whether it exists
                              | or not, diagnosing it incorrectly, and
                              | applying the wrong remedy.--Ernest Benn

I am afraid you would indeed have to merge the documents in your
example. The XPath context for the test expression is at most one
document, so you can't query across two documents here.

Using XSLT for merging the documents is one option, but XProc provides
(probably much more efficient) alternatives: for instance, the
p:wrap-sequence step.

Another approach could be to use p:xquery to query across the documents,
and then use the result of the p:xquery step in your p:choose/p:when.
That would eliminate the need for merging the documents.

Regards,
Vojtech


> -----Original Message-----
> From: public-xml-processing-model-comments-request@w3.org
[mailto:public-xml-
> processing-model-comments-request@w3.org] On Behalf Of fikin
> Sent: Thursday, February 04, 2010 8:59 PM
> To: public-xml-processing-model-comments@w3.org
> Subject: multiple inputs in test expressions?
> 
> i have a case of value lookup withing a secondary input document.
> 
> <p:input name="source" primary="true" />
> <p:input name="src2" />
> <p:choose>
>    <p:when test="/tags/tag[ @name= $src2/tags/tag/@name ]"
>...</p:when>
> </p:choose>
> 
> is there a way to make it working without merging the two documents
> with xslt first?
> 
> 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The following makes use of an old hack, and will do what you need w/o
merging your docs.  You may consider it too ugly to use in practice, I
wouldn't blame you :-)

Note I've gone to all this trouble because I'm _assuming_ that both
source and src2 have many 'tag' daughters of 'tags', each with a
name.

ht

<p:declare-step xmlns:p="http://www.w3.org/ns/xproc" name="top"
version="1.0">
 <p:input port="source" primary="true"/>
 <p:input port="src2"/>
 <p:output port="result"/>
 <p:variable name="src2name"
select="concat('|',string-join(/tags/tag/@name,'|'),'|')">
  <p:pipe step="top" port="src2"/>
 </p:variable>
 
 <p:choose>
  <p:when test="some $name in /tags/tag/@name satisfies
contains($src2name,concat('|',$name,'|'))">
   <p:identity>
    <p:input port="source">
     <p:inline><r>win</r></p:inline>
    </p:input>
   </p:identity>
  </p:when>
  <p:otherwise>
   <p:identity>
    <p:input port="source">
     <p:inline><r>lose</r></p:inline>
    </p:input>
   </p:identity>
  </p:otherwise>
 </p:choose>

</p:declare-step>
- -- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
                         Half-time member of W3C Team
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFLa/uskjnJixAXWBoRAuYhAJ4iLC67XN96MaSPDxhtRY8V+c++JwCfWiSd
fZkv9GOJFxt++PMR4HGZy1E=
=JqZX
-----END PGP SIGNATURE-----

+1 to that

J

On Fri, Jan 22, 2010 at 12:41 PM,  <Toman_Vojtech@emc.com> wrote:
> Right now, the descriptions of the XProc-specific XPath functions in
> section 2.7 use the following for argument and return value types:
>
> string
> String
> boolean
> Node
> xs:decimal
>
> I think we should make this more consistent.
>
> Regards,
> Vojtech
>
>

"Toman_Vojtech@emc.com" <Toman_Vojtech@emc.com> writes:
> Right now, the descriptions of the XProc-specific XPath functions in
> section 2.7 use the following for argument and return value types:
>
> string
> String
> boolean
> Node
> xs:decimal
>
> I think we should make this more consistent.

I would have worded that differently. I would have said something like
this:

  Right now, the descriptions of the XProc-specific XPath functions in
  section 2.7 are a clumsily formatted, hard to read mess. They don't
  stand out from the prose, they aren't consistently formatted, and
  they use an odd mixture of type names. Hey, editor, get a freaking
  clue, why don't you!?

But Vojtech is much too polite to say that :-)

That is, however, what I've felt everytime I've let my eyes pass over
that section. So today, I fixed it. They are now formatted in a manner
consistent with the XPath F&O document.

I think there are probably a few more minor edits to be done, but
surely that's an improvement!

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Where are you dying tonight?--Evelyn
http://nwalsh.com/            | Waugh

"Toman_Vojtech@emc.com" <Toman_Vojtech@emc.com> writes:
> What is the context node for evaluating the "replace" XPath expression
> in p:string replace? The document element (as specified in the section
> "Step XPath context") or the matched node (as I would expect)? It is not
> clear from the description of p:string-replace.

Fixed, per the minutes of 21 Jan 2010.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | To think is not enough; you must think
http://nwalsh.com/            | of something.--Jules Renard

"Toman_Vojtech@emc.com" <Toman_Vojtech@emc.com> writes:

> The "wrapper" attribute is optional, so am I correct in assuming that
> specifying "wrapper-prefix" or "wrapper-namespace" but no "wrapper"
> results in err:XD0034, too?

Per the minutes of 14 January, "yes".

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | The facts, although interesting, are
http://nwalsh.com/            | usually irrelevant.

"Toman_Vojtech@emc.com" <Toman_Vojtech@emc.com> writes:
> Should the XSLT match pattern evaluation follow the value of
> xpath-version? (More of a hack, plus it may stop working in the future).
> Or do we need a new attribute, something like xslt-version? (If so, we
> would need to make it clear that it has no relation to p:xslt
> whatsoever.)

I added a note to section 2.6 per my understanding of the minutes of 7 Jan:

  Note

  In Version 1.0 of XProc, no similar level of control is provided for
  specifying (or testing) the version of XSLT used when evaluating
  XSLTMatchPatterns. The expectation is that XPath 1.0 processors will
  be using XSLT 1.0 match patterns and XPath 2.0 processors will be
  using XSLT 2.0 match patterns, but that is not necessarily the case.

  As XPath, XSLT, and XProc continue to evolve, additional facilities
  for specifying and testing the version of XSLT used to evaluate
  match patterns may be added to XProc.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Oh well, no matter what happens,
http://nwalsh.com/            | there's always death.-- Napoleon