Re: Possible changes for XML 2nd Edition

> Issue PE28:
>
> Currently the XML Recommendation is silent about the handling of
> documents that contain "impossible" bytes.  For example, the byte 0xFF
> cannot appear in any UTF-8 encoded document.  We are considering making
> such violations of the encoding a fatal error.

I guess I'm not sure I see the logic behind any interpretation
of the current (XML 1.0) spec which does NOT make them fatal.

Last time a similar issue came up, I recall comments about parsers
wanting to use OS libraries that might not have ways to report
such decoding errors.  My response is unchanged:  don't use them,
they're buggy.  UTF-8 decoding is easy enough to do right, and
supporting other encodings shouldn't be done with bugs either.


> Issue PE24:
>
> Currently, system identifiers may or may not contain fragment identifiers
> ...
> We are considering changing this language to say that "it is an error" to
> use a fragment identifier.  This would mean that a parser may respect the
> fragment identifier, signal an error, silently ignore the fragment
identifier,
> or even cause demons to fly out of your nose when it finds one.  (:-)).

Usually, specs make demons use a rather different exodus ... :-)


> Is this appropriate?  Are existing parsers ignoring fragment identifiers?
> Should we *require* that an error be signalled?

Yes, require it.  OR at least require that if one is provided, the
fragment identifiers will never (!) be provided to applications, or
get used by the parser.  Just another normalization.

This is an interop issue:  the current spec is fuzzy, and it allows
behaviors which can make implementations fail to interoperate.

- Dave

Received on Thursday, 25 May 2000 09:41:57 UTC