There were two motivating factors: value-typing and elimination of
negative lengths. Value-typing was the catalyst for the change and
elimination negative lengths was a fortunate outcome.
Value Typing:
We have discussed typing at length. We have said that in version 1,
implementations would hardcode typing along with localization. But some
people have argued persuasively that an implementation may want to
process values, at least into integer or character string internal
representations before looking up an attribute to determine its type.
This argues for typing of at least integer and character string without
futher subdivision into booleans and enums for integers for keynames
and dateTimes for character strings. It was also observed there is a
long history of typing fields being useful and that PDF and TIFF have
typing fields. Some people strongly believe that we will eventually
need a typing field, so we should put it in now to avoid a major
revision of the protocol, even if it distinguishes only integer and
character string. These people believe that it is important for a
decoder to be able to fully parse an encoding down to its constituent
values without knowing the semantics. There is some merit to that view.
Negative Lengths:
Negative lengths are a reasonable solution to the problem and we certainly could
continue to live with them. They work. But they need a careful explanation because
negative lengths are unexpected and because the specification of representation of
negative integers assumes 2's complement integer which may not yet be universal.
Neither of these problems argues for eliminating negative lengths per se, but the
solution with tags does seem slightly better.
Summary
At this point, I think we should ask whether there are strong arguments against
this change from a technical view?
For people who are concerned about constant change, I see this as the last change
before we get experience from implementations which will hopefully verify that we
have made good decisions.
Bob Herriot