W3C home > Mailing lists > Public > xproc-dev@w3.org > October 2008

Re: calabash p:delete not working

From: Josh Matthews <joshmatthews@gmail.com>
Date: Sun, 5 Oct 2008 11:46:27 -0400
Message-ID: <ffee23380810050846s588fd7a5u5ec3e26ff9783e2@mail.gmail.com>
To: "Florent Georges" <fgeorges@fgeorges.org>
Cc: mozer <xmlizer@gmail.com>, "Norman Walsh" <ndw@nwalsh.com>, "XProc Dev" <xproc-dev@w3.org>
On Sun, Oct 5, 2008 at 5:47 AM, Florent Georges <fgeorges@fgeorges.org>wrote:

> 2008/10/5 Josh Matthews wrote:
> > Hence, there's no defined error to raise!
>   Well, as you've said, there is a dynamic error for case where the
> value of an option does not match its type, and an empty match pattern
> is not correct.

My suggestion was that this isn't triggered on <p:delete /> (or its
equivalent <p:delete match=""/>), since there is no value of the option at
all (if it was <p:delete match="''", then I'd agree with you - the empty
string isn't valid. But no option at all is not not a valid type, to use a
double negation). It's analogous to the XSLT case which requires the select
attribute of <xsl:apply-templates> to be a valid XPath expression;
<xsl:apply-templates select="" /> isn't an error, because it's the same as
<xsl:apply-templates />, which is valid. In our case the match attribute is
required, but that is dealt with by another error (XS0038) - that fact that
it isn't there at all doesn't trigger the dynamic error XD0019.

So that leaves us with XS0038. My point here is that it's impossible to
detect this error (<p:delete match="//a"/>, when there is no value of //a)
statically, so a strict interpretation of the spec means that this error
can't apply either. Which may be a happy accident, but I think it's good!

>  What about the following:
>    <p:delete>
>        <p:with-option name="match" select="
>            if ( exists(//a) ) then //a else '/..'"/>
>    </p:delete>

Well, yes, that would work - but that comes back to my original point about
XML flexibility. This example introduces a rather complex match pattern just
to get around the fact that XProc throws an error - a much better way is to
have "sensible defaults" that don't require such complexity in the usual
case. I'd suggest the usual case here is that you either want XProc to
delete something if a match expression exists, and delete nothing if it
doesn't. If the user really wants to know if it exists or not (in order to
implement some other logic), they can wrap the <p:delete> in a <p:choose> or
similar, making that logic explicit, rather than embed the logic in an match

Josh Matthews
Received on Sunday, 5 October 2008 15:47:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:03:03 UTC