[
Lists Home |
Date Index |
Thread Index
]
> Still, this change would make some existing major parsers that are
currently
> conformant suddenly non-conformant, and I'm not comfortable doing that
> lightly, for what is mainly a bookkeeping and cleanup release. If all of
> the new properties and features are optional, I don't think that there's
> anything else in the list that would break existing parsers.
Right, my main concern is getting what we have out the door. There is
already a small list of growing features/changes that are not intended for
this release. This is why I quickly agreed with the proposed changes. I
would venture to guess that I am the main voice calling for the endDocument
because of filter chains... if it is not fixed now nothing changes... if it
is fixed then we have to wait on all of the major parsers to support that
change (which should be easy to implement). So in the interim we are back to
no change (experienced).
> > Letting it go either way is the real problem.
>
> Noted. What does everyone else think?
Agreed-- it would be nice to depend on it... seems cleaner. But we can't
now... so any existing filter chain doesn't/shouldn't rely on it. Only new
ones. If it didn't make this release I wouldn't complain... if it did, I
wouldn't complain... unless it took a long time to nail it down.
All the best,
Jeff Rafter
|
