Lists Home |
Date Index |
> I think you are saying that resolving 1) an external entity containing a
> systemID and 2) a URI in general should go through the same resolver: a
> SAX EntityResolver. To do otherwise, would cause confusion. Is this
Pretty much, though the API (EntityResolver2 or whatever) is a
different issue from the implementation underlying it. The core
issue that URIs should be interpreted consistently.
As for the API issue, I fail to see a point for adding another API,
and certainly not inside SAX, duplicating existing functionality.
Defining another API encourages use of secondary/tertiary/...
implementations, creating inconsistency/confusion. But I'm also
aware that large applications are rife with such stuff, maintainance
problems and all. :)
> By resolve, I mean mapping either 1) an external entity to a SAX
> InputSource or 2) mapping some kind of URI in general to a SAX
> InputSource. The URIs in #2 may come from sources other than those
> mentioned in the XML REC itself, such as in XInclude or XML Schema
I think it's perfectly reasonable to pass such stuff through an object
that happens to be a SAX entity resolver. Architecturally, the fact
that some of the URIs happen to come from entity declarations is
one that should be irrelevant to how they are "resolved".