The BNF for the manifest syntax included below is extended as follows:
":":separates the name and value of a rule +: 1 or more *: 0 or more {}: encloses a list of alternatives ;: comment terminals can also be represented in UPPER CASE non-terminals are not encluded in angle brackets Syntax definition from the manifest spec:
In most cases, information contained within the manifest file or signature files is represented as so-called "name: value" pairs inspired by the RFC822 standard.
Groups of name-value pairs are known as a "section". Sections are separated from other sections by empty lines.
Binary data of any form is represented as base64. Continuations are required for binary data which causes line length to exceed 72 bytes. Examples of binary data are digests and signatures.
Implementations shall support header values of up to 65535 bytes.
section: *header +newline nonempty-section: +header +newline newline: CR LF | LF | CR (not followed by LF) ; That 'not followed by LF' probably requires some minor ; ugliness in the parser. Sorry. header: alphanum *headerchar ":" SPACE *otherchar newline *continuation continuation: SPACE *otherchar newline ; RFC822 has +(SPACE | TAB), but this way continuation lines ; never get mangled. alphanum: {"A"-"Z"} | {"a"-"z"} | {"0"-"9"} headerchar: alphanum | "-" | "_" otherchar: any Unicode character except NUL, CR and LF ; Also: To prevent mangling of files sent via straight e-mail, no ; header will start with the four letters "From". ; When version numbering is used: number: {"0"-"9"}+ ; The number needn't be, e.g. 1.11 is considered to be later ; than 1.9. Both major and minor versions must be 3 digits or less.
| |