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

Re: Document template test 10

From: Innovimax W3C <innovimax+w3c@gmail.com>
Date: Wed, 17 Nov 2010 19:07:07 +0000
Message-ID: <AANLkTimm7Qjr=G5SBsnL6amgw5MyNEXwsQyxM_PYmzNz@mail.gmail.com>
To: Norman Walsh <ndw@nwalsh.com>
Cc: public-xml-processing-model-wg@w3.org
My understanding is

If we say the latter : we can have }} inside } irrespective to the
fact that it's in a string or anything else we could rewrite the first
example as
{ concat('{{', /doc/p, '}}') }

And I will be perfectly happy this way

So let's go for this parsing rules

Normal mode
1) IF you parse {{ then output {
2) IF you parse }} then output }
3) IF you parse { then switch to 'xpath mode'
4) IF you parse } then it's an error
5) IF you parse anything else output it as is

Xpath mode
1) IF you parse {{ then output {
2) IF you parse }} then output }
4) IF you parse { then it's an error
3) IF you parse } then switch to 'normal mode' and evaluate the string
in the buffer as the xpath expression
5) IF you parse anything else output it as is

Mohamed

On Wed, Nov 17, 2010 at 3:33 PM, Norman Walsh <ndw@nwalsh.com> wrote:
> The heart of test 10 is this expression:
>
>  {{{/doc/p}}}
>
> There are two possible interpretations:
>
> "{" "/doc/p" "}"
>
> or
>
> "{" "/doc/p}" "}"
>
> The former yields a valid expression, the latter an invalid one.
>
> The problem I have is this case:
>
> { concat('{{', $foo, '}}') }
>
> There are two possible interpetations here too:
>
> " concat('{', $foo, '" ... error because there's an unbalanced "}"
>
> or
>
> " concat('{', $foo, '}') "
>
> If we say that "}" ends an expression when we're inside one, then the
> first expression is valid and the second is not. If we say that "}}"
> is matched even when we're inside an expression then the first
> expression is invalid and the second is valid.
>
> On the whole, I prefer the latter interpretation. In either case,
> there are some sequences of values that cannot be constructed using
> the document-template step. We'd have to have more complex parsing
> rules to avoid that problem, but I'd rather not.
>
>                    Be seeing you,
>                     norm
>
> --
> Norman Walsh
> Lead Engineer
> MarkLogic Corporation
> www.marklogic.com
>



-- 
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 Wednesday, 17 November 2010 19:07:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 17 November 2010 19:07:41 GMT