[Pmt-exif] Re: Exif and PNG

[Adam M. C. <am...@cs...>]

Glenn Randers-Pehrson <gl...@ho...> wrote:

> I still don't much like the "\n=" having a dual purpose of
> keyword-terminator and escaped-newline.

We're still not on the same wavelength.  Let me once more clarify how
I view my syntax, and then I'll propose a restriction on your syntax
that makes it more palatable to me (perhaps even more attractive than my
own).

I don't think of my syntax as escaping anything; in fact the whole point
of it is to avoid the need for anything to be escaped or quoted.

Every newline character means the same thing: the end of the line.  The
parser is always in the same state at the start of every line.

Here's the entire syntax spec:  Every line has the form
[keyword][=valueline], where either half may be missing.  If the
valueline is present, it gets appended to the value of the most recent
keyword you've seen.

So a key/value pair is not terminated by a newline.  It's terminated by
the appearance of the next keyword, or the end of the chunk.  Therefore
it is not necessary to escape newlines.

Your counter-proposal has a quirk that I'm having a hard time making
sense of:

firstkey=one
secondkey=two
=
=three
thirdkey=
=four
=five

If the value of secondkey is three lines with the second line blank,
then the value of thirdkey must be three lines with the first blank.
It's so obvious that it would be cruel to specify otherwise.

One way out is to forbid the form used by secondkey.  You could require
that key/value pairs either use the one-line syntax, or the value *must*
be on its own lines.  Then it becomes completely arbitrary whether a
line with a key and no value has an equal sign or not, and I'd have
no objection to requiring the equal sign.  The syntax could then be
described:

A key/value pair has either the form keyword=value (on one line),
or keyword= on one line and zero or more instances of =valueline on
subsequent lines.  The latter form allows for multi-line values.

Come to think of it, thinking of the syntax as a choice between two
separate syntaxes provides another opportunity:  You could say that for
the keyword=value syntax the newline is not part of the value, but for
the =valueline syntax all the newlines in the =valueline lines are part
of the value (including the one in the last line).  For EXIF data it
probably doesn't matter, but in other applications you sometimes want to
distinguish between

foo=some text (no newline)

versus

foo=
=one line of text (ending with a newline)

And hey, here's something neat:  If you wanted the value of foo to be
the empty string, you would say:

foo=

Is that a degenerate case of the one-line syntax or the multi-line
syntax?  Both!  And it's still the empty string (not even a newline)
either way you look at it.  If you wanted a single blank line (a single
newline character), you would say:

foo=
=

Do you still see a need to ignore up to one whitespace character after
an equal sign?  With the secondkey syntax forbidden, I think it would be
an unnecessary complication.

AMC