Paul, about the double redirection: I don't think you can use the catalog
like that because the the URI resolver does a single pass through the
catalog. If I understand correctly, to do what your proposing it would
have to recurse: first locate the namespace -> remote location, then call
itself
Paul Fullbright wrote:
The XML Catalog specification can be found here:
http://www.oasis-open.org/committees/entity/specs/cs-entity-xml-catalogs-1.0.html
Yes, I tried to digest it, without much luck. There seems to be a lot
of circular definition, such as: "The system entry indicates that
The XML Catalog specification can be found here:
http://www.oasis-open.org/committees/entity/specs/cs-entity-xml-catalogs-1.0.html
Yes, I tried to digest it, without much luck. There seems to be a lot
of circular definition, such as: "The system entry indicates that an
entity manager must
Paul,
The XML Catalog specification can be found here:
http://www.oasis-open.org/committees/entity/specs/cs-entity-xml-catalogs-1.0.html
One thing to keep in mind is that a Namespace isn't necessarily a
resolvable web location. It's just a unique identifier for a set of
elements.DTDs
Thank you, Valentin, for the helpful reply.
One fairly dumb question first: without digesting all the nuances of
the OASIS specification, what exactly are the differences between the
"public", "system", and "uri" extensions? It looks like
org.eclipse.jst/wst.standard.schemas use primarily "p
Valentin Baciu wrote:
If in the future this type of version driven schema location becomes
widespread, and use case 2 is preferred (as in the XSLT case), perhaps
we could:
- enhance the XML catalog resolver to directly support this
scenario
- generalize the XSLT custom resolve
