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

Re: Remarks on W3C Editor's Draft 6 August 2007

From: Innovimax SARL <innovimax@gmail.com>
Date: Tue, 14 Aug 2007 08:18:11 +0200
Message-ID: <546c6c1c0708132318i23d17c39yc2383e40d4820c20@mail.gmail.com>
To: "Alex Milowski" <alex@milowski.org>
Cc: "XProc WG" <public-xml-processing-model-wg@w3.org>

On 8/14/07, Alex Milowski <alex@milowski.org> wrote:
>
> On 8/13/07, Innovimax SARL <innovimax@gmail.com> wrote:
> > On 8/13/07, Alex Milowski <alex@milowski.org> wrote:
> > >
> > > 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".
> >
> > Sorry, I misunderstand
> > I would say that to be fully consistent with XPath, the answer should
> > "true" or "false"
> >
>
> While I agree with you on that, we choose to be inconsistent with
> XPath for boolean option values.  This would be the only place
> where booleans have the values "true" and "false".
>
> I'd rather that boolean values be consistent with the xsd:boolean
> simple type but I seem to have lost out to those that prefer being
> consistent with XSLT's use of "yes" and "no".
>
> Our use of "yes" and "no" as literal value will prevent us from
> ever typing boolean options as xs:boolean in some future version
> of XProc.  That is, unless XML Schema allows different enumerated
> values for booleans--but don't hold your breath for an XML Schema
> 2.0 because 1.1 took a very long time and it still isn't a recommendation.

Ok let's see where we stand

I think the better of both world (say XSLT and boolean XPath) is to
allow everywhere someone has to type something to have (yes/no) and
(true/false) for the case this value could be given by XPath

I think, this is already the case in XProc

The case, you speak about, is when XProc has to define a boolean value
that should written by the processor

In that case, the previous option was to have (0/1). I think that to
be consistent and open for the future, that the best solution is to
write (true/false)

Then we won't have to wait for XML Schema 2.0

Mohamed

-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 9 52 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 
Received on Tuesday, 14 August 2007 06:18:16 GMT

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