[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Possible changes for XML 2nd Edition

• From: "David Brownell" <david-b@p...>
• To: <xml-editor@w...>, <xml-dev@x...>
• Date: Thu, 25 May 2000 15:42:59 +0200

> 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



***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************

• References:
  • Possible changes for XML 2nd Edition
    • From: John Cowan <jcowan@r...>

• Prev by Date: Re: Possible changes for XML 2nd Edition
• Next by Date: Re: Possible changes for XML 2nd Edition
• Previous by thread: Re: Possible changes for XML 2nd Edition
• Next by thread: Re: Possible changes for XML 2nd Edition
• Index(es):
  • Date
  • Thread