Subject: RE: Query on case insensitivity

From: [email-masked]
Date: Wed, 20 Jun 2001 20:53:40 +0530

Hi

 I am a bit concerned about the first point.
Maybe its a bit too late, or simply irrelevant, but still I would like to put
forth this point.

 Allowing a message to contain a mixture of short and long tokens will
needlessly complicate the parser.
     For tokens like the one for Error, which has a short token 'Er' and a long
one 'Error'
the parser would have to look ahead to the 3rd character to conclude whether it
is the shorter version of
Error token, or it is halfway thru the long 'Error' token or whether it is
simply an syntax error. If we put a small
restriction, that the messages should contain only one kind of tokens, it would
atleast do away with one of the possibilities.
     Parsing is a CPU intensive process and such small restrictions would be a
major help.
     It will make life simpler for the parser, and perhaps make the messages
more elegant.

Regards
Shiv

"Rosen, Brian" <[email-masked]> on 06/20/2001 05:58:32 PM

To:   Amit Kalra/HSS@HSS, [email-masked]
cc:    (bcc: Shiv Kumar/HSS)

Subject:  RE: Query on case insensitivity

The answer to all of your queries is yes

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, June 20, 2001 1:27 AM
> To: [email-masked]
> Subject: Query on case insensitivity
>
>
>
>
> Hi all,
>      ABNF syntax notation is CASE INSENSITIVE, apart from the
> SDP and whatever
> comes within quotes should not be validated.
> My queries:
> 1.  In case of short and long tokens can we mix both of them like
>
>      MEGACO/1 [123.123.123.123]:55555
>           P = 50005 {
>                Context = - { N = A5555 }
> Is it allowed?
>
> 2.  Can we have tokens like   "TranACTIONresponSEAck" , I
> mean mix of lower and
> upper case in one token ?
>
> 3. Can we have short tokens in lower case or mix case like
> "rc" or "rC"  for
> ReceiveOnly ?
>
> regards/
> Amit
>
>

---

From: "Madhu Babu Brahmanapally" <[email-masked]>
Date: Wed, 20 Jun 2001 11:32:34 -0400

Hi Shiv,all,
I agree with shiv's argument. First of all, I am not clear why there are two
set of tokens. The long tokens doesn't convey any extra information (except
for debugging purposes). In terms of efficiency obviously the short tokens
will be the better choice. And having a mix of both unnecessarily
complicates the parser.

Regards
Madhubabu

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of
[email-masked]
Sent: Wednesday, June 20, 2001 11:24 AM
To: [email-masked]
Subject: RE: Query on case insensitivity

Hi

 I am a bit concerned about the first point.
Maybe its a bit too late, or simply irrelevant, but still I would like to
put
forth this point.

 Allowing a message to contain a mixture of short and long tokens will
needlessly complicate the parser.
     For tokens like the one for Error, which has a short token 'Er' and a
long
one 'Error'
the parser would have to look ahead to the 3rd character to conclude whether
it
is the shorter version of
Error token, or it is halfway thru the long 'Error' token or whether it is
simply an syntax error. If we put a small
restriction, that the messages should contain only one kind of tokens, it
would
atleast do away with one of the possibilities.
     Parsing is a CPU intensive process and such small restrictions would be
a
major help.
     It will make life simpler for the parser, and perhaps make the messages
more elegant.

Regards
Shiv

Brian

---

From: Troy Cauble <[email-masked]>
Date: Wed, 20 Jun 2001 11:31:26 -0400

>      It will make life simpler for the parser, and perhaps make the messages

So instead it would have to look at a state variable
to tell whether you should look at the next character?!
That doesn't remove any possibilities.
Or do you want to write two complete lexers?!

NO NO NO.  Your restriction would make it harder not easier.

In (f)lex:

Error|ER                        { return ErrorToken; }

Simple yes?

-troy

---

From: Al Varney <[email-masked]>
Date: Wed, 20 Jun 2001 11:20:38 -0500

>will be the better choice. And having a mix of both unnecessarily

    If parsing efficiency is a concern, then removing the case 
insensitivity would be a much bigger gain than reducing the size of the 
dictionary (having only ER or ERROR, for example).

Al Varney - Lucent Technologies  +1 630 224-7493    [email-masked]