- From: Josh Matthews <joshmatthews@gmail.com>
- Date: Sun, 5 Oct 2008 11:46:27 -0400
- To: "Florent Georges" <fgeorges@fgeorges.org>
- Cc: mozer <xmlizer@gmail.com>, "Norman Walsh" <ndw@nwalsh.com>, "XProc Dev" <xproc-dev@w3.org>
- Message-ID: <ffee23380810050846s588fd7a5u5ec3e26ff9783e2@mail.gmail.com>
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 pattern. Cheers, Josh Matthews
Received on Sunday, 5 October 2008 15:47:02 UTC