Re: n3 grammar : ambiguity for integer and decimal

Tim,

Thank you to take care of my spot.

An other ambiguity I discovered writing n3 parser that I did not mentionned is about "is" "of" and "a" keyword.
There is no problems with "@is", "@of", and "@a" since the @ make able to distinguish to a qname, it is not the case with "is" "of" and "a" keyword because it also match qname non terminal.

I have this since I have the following rules not in n3 grammar:
  verb <- ( "is" | "@is" ) expression ( "of" | "@of" )

for the entry  " :jmv is :guru of :luc ."

it match at the same time

    simpleStatement 
      |
      subject propertylist
      |       |
      |       verb object objecttail propertylisttail
      |       |    |      |          |
      |       |    |      void       void
    :jmv      is   :guru

  and


    simpleStatement 
      |
      subject propertylist 
      |       |
      |       verb                  object objecttail propertylisttail
      |       |                     |      |          |
      |       "is" expression "of"  |      |          |
      |       |    |          |     |      |          |
    :jmv      is   :guru      of    :luc   void       void

so there is a shift/reduce conflict between
verb <- expression
and
verb <- is expression of

this can be solve saying qname can not have the value "is" "of"

Best regards
Luc Peuvrier

----- Original Message ----- 
  From: Tim Berners-Lee 
  To: luc peuvrier at home 
  Cc: cwm talk ; DIG group ; Yosi Scharf 
  Sent: Saturday, February 21, 2009 12:40 AM
  Subject: Re: n3 grammar : ambiguity for integer and decimal


  Luc, thanks for spotting that.


  It seems to make sense.  I have checked it in as the new n3.n3




  Tim


  On 2009-02 -12, at 18:26, luc peuvrier at home wrote:


    Hi,

    Looking for integer and decimal non terminal ( token ) definition on following n3 grammar specification:
      http://www..w3.org/2000/10/swap/grammar/n3-report.html

      and

      http://www.w3.org/2000/10/swap/grammar/n3.n3

    The ebnf definition for integer and decimal are:

      integer : [-+]?[0-9]+

      decimal : [-+]?[0-9]+(\.[0-9])?

    There is an ambiguity since "123" ( for example ) match integer and decimal

    I propose
      decimal : [-+]?[0-9]+\.[0-9]*

    Width the above definition "123" match only integer, "123." match decimal. This look like C and Java standard for numéric constants

    Best regards
    Luc Peuvrier