W3C home > Mailing lists > Public > public-xml-processing-model-wg@w3.org > July 2007

Re: XProc Editors Draft 2007-07-19: Appendix A.1 Comments

From: Norman Walsh <ndw@nwalsh.com>
Date: Tue, 24 Jul 2007 11:39:01 +0100
To: public-xml-processing-model-wg@w3.org
Message-ID: <87myxm3x2y.fsf@nwalsh.com>
/ Jeni Tennison <jeni@jenitennison.com> was heard to say:
| Innovimax SARL wrote:
|> On 7/24/07, Jeni Tennison <jeni@jenitennison.com> wrote:
|>> Innovimax SARL wrote:
|>> > On 7/23/07, Jeni Tennison <jeni@jenitennison.com> wrote:
|>> >> A.1.3 Equal: The fail-if-not-equal option hasn't been described. Why
|>> >> return "1" or "0" rather than the more human-readable "true" or "false"?
|>> >
|>> > I think it match directly boolean() of XPath, isn'it ?
|>>
|>> The string value of boolean true is "true". The string value of boolean
|>> false is "false". Only if you first convert the boolean to a number do
|>> you get the strings "0" and "1".
|>
|> yes but every where else we use "yes/no"
|> that's why I found less confusing "0/1" for boolean à la XPath and
|> yes/no boolean à la XSLT
|
| But 0/1 isn't boolean a la XPath (true/false) is. I would be happy with yes/no
| instead, since that's what we've used elsewhere. It's just 0/1 that I find
| objectionable.

The fact that computing the values "yes" and "no" with XPath 1.0 is
much harder than generating "true" and "false" makes me think that we
should revisit the spelling of boolean values.

I think I'm (personally) convinced that we should accept either "yes"
or "true" and "no" or "false" everywhere that we have boolean yes|no
choices today.

|> may be we should take a look at XQuery Update
|> -- your proposal --
|> 3.1.1 upd:insertBefore
|> 3.1.2 upd:insertAfter
|> -- /your proposal
|>
|> 3.1.3 upd:insertInto (we don't need this one)
|>
|> -- the status quo --
|> 3.1.4 upd:insertIntoAsFirst
|> 3.1.5 upd:insertIntoAsLast
|> -- /the status quo --
|>
|> 3.1.6 upd:insertAttributes (this one is A.1.15 Set Attributes)
|>
|> may be we should just provide both
|>
|> <p:option name="position" default="as-first" />
|> and allowed values "as-first", "as-last", "after", "before"
|
| You're right: I think all four options would be useful. I'd have position be
| "first-child", "last-child", "after" and "before". I'm not sure there's an
| obvious default, which makes me think that it should be a required option.

Works for me.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com> | Someone has changed your life. Save?
http://nwalsh.com/            | (y/n)

Received on Tuesday, 24 July 2007 10:46:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:21:53 GMT