W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2005

[Bug 1383] New: [XQuery] some editorial comments on A.2 Lexical structure

From: <bugzilla@wiggum.w3.org>
Date: Wed, 11 May 2005 07:35:44 +0000
To: public-qt-comments@w3.org
Cc:
Message-Id: <E1DVlku-0001AB-SH@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1383

           Summary: [XQuery] some editorial comments on A.2 Lexical
                    structure
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQuery
        AssignedTo: chamberl@almaden.ibm.com
        ReportedBy: jmdyck@ibiblio.org
         QAContact: public-qt-comments@w3.org


A.2 Lexical structure

[See a later comment for suggested alternate wording.]

Thanks for excising the state machine!

"and [XML Names]are"
    Insert space before "are".

"When patterns are simple string matches, the strings are embedded directly into
the EBNF. In other cases, named terminals are used."
    Delete. It doesn't say anything that isn't already said better in the EBNF
    notation section. Plus it isn't connected to anything else in the section.

"that together may help disambiguate the individual symbols."
    Ditto my comments re this sentence in A.1.

"When tokenizing, the longest possible match that is valid in the current
context is preferred ."
    Delete space before period.

    What constitutes "the current context"? What constitutes "valid"?  Longest
    match of what?  Given that tokenization is up to the implementor, it seems
    that the effect of this sentence would vary between implementations, which
    is probably not what you want.

    Luckily, I think this rule can be deleted. The rules about required
    whitespace (to prevent two adjacent terminals from being mis-recognized as
    one) should (if fixed) handle anything that the "longest possible match"
    would have.
Received on Wednesday, 11 May 2005 07:35:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:05 UTC