RE: Re[2]: Testcases for HTTP location grammar [CR130]

Yes.  Sorry for the typos!

Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com
 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On
> Behalf Of [email protected]
> Sent: Friday, January 12, 2007 12:13 PM
> To: [email protected]
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]
> Subject: Re[2]: Testcases for HTTP location grammar [CR130]
> 
> 
> >I think I agree.  I don't like either of the result sets John presents.
> >FWIW, here's what I would expect:
> >
> 
> If I am understanding your algorithm correctly, there seem to be a few
> typos in the examples you gave.
> For the sake of clarity, would the following be what you had in mind?
> 
> >"{town}"       > {town}           > "Paris"     > valid
> >"{{town}}"     > {{,town,}}       > "{Paris}"   > valid
> 
>                                      "{town}"
> 
> >"{{{town}}}"   > {{,{town},}}     > "{Paris}"   > valid
> >"{{{{town}}}}" > {{,{{,town,}},}} > "{{Paris}}" > valid
> 
>                                      "{{town}}"
> 
> >"{{town}"      > {,{town}         > "{Paris"    > invalid
> 
>                   {{, town}        > (invalid anyway)
> 
> >"{{{town}"     > {{,{town}        > "{Paris"    > valid
> >"{town}}"      > {town},}         > "Paris}"    > invalid
> >"{town}}}"     > {town},}}        > "Paris}"    > valid
> >
> >
> >I don't know if it's Tony's algorithm, but I mentally parse it as reading
> >left to right, consuming {{ and emitting {, consuming {name} and
> replacing
> >it with the data, and consuming }} and emitting }.  I'm sure Philippe
> will
> >come up with a clean formulation with the maximum number of "valid"
> results.
> >
> >
> >
> >Jonathan Marsh -  <http://www.wso2.com> http://www.wso2.com -
> ><http://auburnmarshes.spaces.live.com>
> http://auburnmarshes.spaces.live.com
> >
> >
> >
> >  _____
> >
> >From: [email protected] [mailto:[email protected]] On
> >Behalf Of Rogers, Tony
> >Sent: Thursday, January 11, 2007 5:50 PM
> >To: John Kaputin (gmail); Philippe Le Hegaret; [email protected]
> >Subject: RE: Testcases for HTTP location grammar [CR130]
> >
> >
> >
> >I think the parser need to have a stack for braces - I don't believe even
> a
> >state machine can hold all the information we need - when we match up a
> pair
> >we need to know what our state was before we opened that pair. My sketch
> of
> >the processing would go:
> >
> >
> >
> >if the next character is {
> >
> >a. if previous character was { and top of stack is { then change top of
> >stack to {{
> >
> >b. otherwise stack {  (remembering where it was seen)
> >
> >
> >
> >if the next character is }
> >
> >a. if top of stack is {{ look for another } immediately following
> >
> >    i. if next char is }, unstack the {{  - we have a matching pair  {{}}
> >
> >    ii. if next char is not }, throw error or treat as literal }
> >
> >b. if top of stack is {, unstack the {  - we have a matching pair {}
> >
> >c. if stack is empty, throw error or treat as literal }
> >
> >
> >
> >at the end, the stack should be empty, assuming all { matched },
> otherwise
> >unstack the extras and treat as literals (which is why we remembered
> their
> >locations)
> >
> >
> >
> >To put it into words, I see } or }} as matching to the nearest unpaired {
> or
> >{{, but always respecting nesting. I also see longer sequences of { taken
> as
> >pairs until there's one or none left.
> >
> >
> >
> >So to my mind {{{{X}}}} parses as {{  {{  X  }}  }}  - even though that's
> a
> >questionable construct.  Or do we want to add another rule saying that {{
> >cannot be nested inside {{ ?
> >
> >
> >
> >How does that sound?
> >
> >
> >
> >Tony Rogers
> >
> >CA, Inc
> >
> >Senior Architect, Development
> >
> >[email protected]
> >
> >co-chair UDDI TC at OASIS
> >
> >co-chair WS-Desc WG at W3C
> >
> >
> >
> >  _____
> >
> >From: [email protected] on behalf of John Kaputin (gmail)
> >Sent: Fri 12-Jan-07 8:50
> >To: Philippe Le Hegaret; [email protected]
> >Subject: Testcases for HTTP location grammar [CR130]
> >
> >Phillipe,
> >Today's working group call concluded that a grammar should define how the
> >http location is parsed and you have the action, so as discussed I'm
> sending
> >you some of my testcases. My post [1] is now captured as CR130.
> >
> >In deciding on the grammatical rules, things to consider include the
> >precedence of double curly braces versus single braces and how to match
> >pairs of single braces - e.g. by scanning from left to right, by 'inner
> most
> >pair' (or whatever the terminology is), etc.
> >
> >When trying several approaches in Woden I found it's not as simple as
> 'find
> >a left curly brace, check for a double brace, then scan for a right curly
> >brace'. Also, it appeared from my initial interpretation of the spec that
> >double curly braces should take precedence over single braces, but this
> >produced some unexpected results. A better approach seems to be 'inner
> most
> >pair' takes precedence, then double curly braces, then other single
> braces.
> >
> >Below are some test cases using different approaches. "Valid/invalid"
> simply
> >indicates whether non-paired single braces end up in the parsed string
> >(literal single braces are okay).
> >
> >Inner-most pair, then doubles, then unpaired singles. town=Paris:
> >
> >"{town}"       > {town}           > "Paris"     > valid
> >"{{town}}"     > {,{town},}       > "{Paris}"   > invalid
> >"{{{town}}}"   > {{,{town},}}     > "{Paris}"   > valid
> >"{{{{town}}}}" > {{,{,{town},}},} > "{{Paris}}" > invalid
> >"{{town}"      > {,{town}         > "{Paris"    > invalid
> >"{{{town}"     > {{,{town}        > "{Paris"    > valid
> >"{town}}"      > {town},}         > "Paris}"    > invalid
> >"{town}}}"     > {town},}}        > "Paris}"    > valid
> >
> >Double braces first, then pairs of singles left-to-right. town=Paris:
> >
> >"{town}"       > {town}           > "Paris"     > valid
> >"{{town}}"     > {{,town,}}       > "{town}"    > valid
> >"{{{town}}}"   > {{,{,town,}},}   > "{{town}}"  > invalid
> >"{{{{town}}}}" > {{,{{,town,}},}} > "{{Paris}}" > invalid
> >"{{town}"      > {{,town,}        > "{town}"    > invalid
> >"{{{town}"     > {{,{town}        > "{Paris"    > valid
> >"{town}}"      > {,town,}}        > "{town}"    > invalid
> >"{town}}}"     > {,town,}},}      > "{town}}"   > invalid
> >
> >Other test cases:
> >
> >""                      (is an   empty string location valid?)
> >"/temperature/"
> >"/temperature/{town}/"
> >"/temperature/{town}/{state}/{country}"
> >"/temperature/{town}/{{{state}}}/{country}"
> >
> >It would be good if the spec could include similar examples and/or if the
> >test suite covered the grammar.
> >
> >regards,
> >John Kaputin
> >
> >[1] http://lists.w3.org/Archives/Public/www-ws-desc/2007Jan/0045.html
> >
> >
> 
> --
> Best regards,
> Georgi Georgiev