[
Lists Home |
Date Index |
Thread Index
]
"Arnold, Curt" wrote:
>
> Schema location resolution is not just a special case and is more complex
> than just URI redirection. An application would typically want to locate a
> schema resource by the namespace URI or the namespace URI plus some
> additional information (such as the version attribute on an <xsl:transform>
> element) and ignore any xsi:schemaLocation hint.
>
> Since schema validation augments the infoset, it is necessary (or at least
> useful) to resolve the location during the parsing of the document.
>
> Sandy Gao, others and I had a very long discussion on this on the
> Xerces-J-Dev mailing list in August 2001
> (http://archive.covalent.net/xml/xerces-j-dev/2001/08/0119.xml and
> following). I believe that most of that got reflected in the Xerces-J 2's
> schema resolution interfaces, but I haven't really followed it.
I haven't looked at the code in detail so I could be mistaken, but I
believe, currently, when the parser encounters an xsi:shemaLocation
attribute, the schema-location-URI portion is the only part that goes
through redirection by being passed in as the systemID param of a SAX
EntityResolver if any.
>
> Basically, my take was that the parser should throw an event when it
> encounters content that it cannot find an existing schema resource to
> handle. The handler should have access to any previously encountered
> xsi:schemaLocation, the namespace URI and local name of the content that
> caused the event and the untyped content of the start tag (so that you could
> use something like an version attribute).
Perhaps, there are plans to implement a more general scheme in the
future.
-Edwin
|
