- From: Alex Milowski <alex@milowski.org>
- Date: Mon, 13 Aug 2007 14:42:50 -0700
- To: "XProc WG" <public-xml-processing-model-wg@w3.org>
On 8/13/07, Innovimax SARL <innovimax@gmail.com> wrote: > On 8/13/07, Alex Milowski <alex@milowski.org> wrote: > > > > On 8/8/07, Innovimax SARL <innovimax@gmail.com> wrote: > > > > > > s/A.2.1 Add Attributes/A.2.1 Add Attribute/ > > > > > > Please specify also the XPath Context for the match option > > > > > > == boolean == > > > > > > Please fix the inconsistencies between yes/true/no/false everywhere > > > and and clarify this position for p:equal (which currently generates > > > 0/1) > > > > All options that are booleans use 'yes' and 'no'. Only XPath expression > > evaluations use 'true' and 'false' as logical values. > > > > p:equal does need to be clarified as to what is in the c:result > > element. > > > > "yes" and "no" or "true" or "false" ? > > > > Opinions anyone? > > > It seems this issue was already raised and solved > > The problem is that everywhere we have an option which need to have a > boolean value, it's just a pain to make it work with yes/no > So yes/no and adding true/false seems just good to me I was not suggesting we add "true/false" to option values. Only asking what the value of the c:result element should be for p:equals. If we wanted to be totally consistent, we'd use the literals "yes" and "no". -- --Alex Milowski "The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered." Bertrand Russell in a footnote of Principles of Mathematics
Received on Monday, 13 August 2007 21:42:56 UTC