xml-dev - Re: Possible changes for XML 2nd Edition

[John Cowan <jcowan@reutershealth.com>]

Steve DeRose wrote:

> I do not see any reason to rule out fragment identifiers in system identifiers.
> There are lots of potential uses for them. Consider:

[list of good examples snipped]

> What motivation could there be for absolutely prohibiting fragment
> identifiers?

Rightly or wrongly, XML processors are licensed to signal an error if
they detect a fragment id in a system identifier, at least in the case
when the system identifier appears in an entity declaration.  (Fragment ids
in system identifiers in notation declarations are more doubtful, but
such system identifiers are typically not processed by the parser but
simply passed to the application.)  Nobody can depend on using such a
fragment id in an XML document that is intended to be interoperable.

We believe that many parsers silently ignore fragment ids, a
behavior which the XML Rec does not license.  The question is:

	a) license ignoring fragment identifiers by saying "it is an
	   error" to use them, or

	b) require that parsers either:
		b.1) process the fragment id according to the media type, or
		b.2) signal an error such as "Unable to accept fragment id".

> It seems to me it's none of XML's business what the syntax of
> URI references is, or whether fragment identifiers are needed. What of a
> media type which defines the fragment identifier (they are media type
> specific, after all) in such a way that it ends up being *required* for
> proper interpretation, or for any feasible use? there is no principled
> reason this can't happen, so I think XML should stay comletely out of the
> issue.

Too late now.

-- 

Schlingt dreifach einen Kreis um dies! || John Cowan <jcowan@reutershealth.com>
Schliesst euer Aug vor heiliger Schau,  || http://www.reutershealth.com
Denn er genoss vom Honig-Tau,           || http://www.ccil.org/~cowan
Und trank die Milch vom Paradies.            -- Coleridge (tr. Politzer)

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