You keep a local copy of the schema and define an org.xml.sax.EntityResolver to return an InputSource constructed on the local url when resolving the remote url. You do *not* change the namespaces.
Alternatively, you add external schema locations to the parser for the namespaces in question, associating each namespace with a local file containing the schema definition. This works with Xerces parsers and possibly others. If you have local copies, you can modify the <import> elements to point to the local copies, and modify the wsdl (for which you presumably also have a local copy) to point to the local copy of the schemas it references. Jeff On 4/7/06, Martin Gainty <[EMAIL PROTECTED]> wrote: > > how is the schema resolved when there is no access to outside environment? > M- > > ----- Original Message ----- > From: Anne Thomas Manes > To: [email protected] ; Martin Gainty > Sent: Friday, April 07, 2006 2:29 PM > Subject: Re: Monitor progress of an AXIS SOAP request and response over http > transport > > A namespace URI does *not* need to be resolvable. A namespace URI is simply > a name. Also, if you change the URI for the "soap" namespace to a local file > URL, (e.g., change xmlns:soap=" > http://schemas.xmlsoap.org/wsdl/soap/"; to > "xmlns:soap=file://fu/bar/fubar/") The WSDL parser will not recognize the > SOAP extensibility elements, and the WSDL won't parse properly. The only > URIs that must resolve to an actual URL are those used to locate Schema or > WSDL files (the location and schemaLocation attributes) in <wsdl:import>, > <xsd:import> and <xsd:include> statements. > > Anne > > > On 4/7/06, Martin Gainty <[EMAIL PROTECTED]> wrote: > > Sure thing > > (To All..this response is somewhat long-winded..) > > > > first tns is a short way to say 'this namespace' > > > > The definition of namespaces available at > > http://www.w3.org/TR/REC-xml-names/#ns-decl > > states > > NAMES from XML namespaces may appear as qualified names, which contain a > single colon, separating the name into a namespace prefix and a local part. > The prefix, which is mapped to a URI reference, selects a namespace. The > combination of the universally managed URI namespace and the document's own > namespace produces identifiers that are UNIVERSALLY UNIQUE. > > an example of a namespace prefix is > > <x xmlns:edi='http://ecommerce.org/schema'> > > <!-- the "edi" prefix is bound to http://ecommerce.org/schema > > for the "x" element and contents --> > > </x> > > /*Note http://ecommerce.org/schema MUST be reachable */ > > /*Also*/ > > "An XML namespace is a collection of names, identified by a URI reference > [RFC2396], which are used in XML documents as element types and attribute > names" > > > > a quick lookup on URI (we can view the original spec publish by Tim > Berners-Lee at MIT) at http://www.ietf.org/rfc/rfc2396.txt > > where Tim states > > "A URI can be further classified as a locator, a name, or both. The > > term "Uniform Resource Locator" (URL) refers to the subset of URI > > that identify resources via a representation of their primary access > > mechanism (e.g., their network "location"), > > rather than identifying > > the resource by name or by some other attribute(s) of that resource. > > The term "Uniform Resource Name" (URN) refers to the subset of URI > > that are required to remain globally unique and persistent even when > > the resource ceases to exist or becomes unavailable." > > /*Note the forward thinking on this strategy so that if URN server 1 goes > down ..URN server2 can kick in provided the schema stays consistent Here are > some real world examples: */ > > The following examples illustrate URI that are in common use. > > ftp://ftp.is.co.za/rfc/rfc1808.txt > > -- ftp scheme for File Transfer Protocol services > > > gopher://spinaltap.micro.umn.edu/00/Weather/California/Los%20Angeles > > -- gopher scheme for Gopher and Gopher+ Protocol services > > http://wwwmath.uio.no/faq/compression-faq/part1.html > > -- http scheme for Hypertext Transfer Protocol services > > mailto:[EMAIL PROTECTED] > > -- mailto scheme for electronic mail addresses > > news:comp.infosystems.www.servers.unix > > -- news scheme for USENET news groups and articles > > telnet://melvyl.ucop.edu/ > > -- telnet scheme for interactive services via the TELNET Protocol > > > > /*here is a URI definition declared elsewhere..*/ > > <import namespace="uri:diy" location=" binding.wsdl"/> > > > > /*All of the above examples conform to the syntactic requirements of the > spec addressed within the RFC2396 spec stated here*/ > > > > 3. URI Syntactic Components > > The URI syntax is dependent upon the scheme. In general, absolute > > URI are written as follows: > > /*Absolute spec defined here */ > > <scheme>:<scheme-specific-part> > > > > An ABSOLUTE URI contains the name of the scheme being used (<scheme>) > > followed by a colon (":") > > and then a string (the <scheme-specific-part>) whose interpretation > DEPENDS on the scheme. > > > > The URI syntax does not require that the scheme-specific-part have > > any general structure or set of semantics which is common among all > > URI. However, a subset of URI do share a common syntax for > > representing hierarchical relationships within the namespace. This > > "generic URI" syntax consists of a sequence of four main components: > > > > <scheme>://<authority><path>?<query> > > > > each of which, except <scheme>, may be absent from a particular URI. > > For example, some URI schemes do not allow an <authority> component, > > and others do not use a <query> component. > > > > absoluteURI = scheme ":" ( hier_part | opaque_part ) > > > > URI that are hierarchical in nature use the slash "/" character for > > separating hierarchical components. For some file systems, a "/" > > character (used to denote the hierarchical structure of a URI) is the > > delimiter used to construct a file name hierarchy, and thus the URI > > path will look similar to a file pathname. This does NOT imply that > > the resource is a file or that the URI maps to an actual filesystem > > pathname. > > > > hier_part = ( net_path | abs_path ) [ "?" query ] > > > > net_path = "//" authority [ abs_path ] > > > > abs_path = "/" path_segments > > > > /*In both absolute and general implementations one must define and > identify a schema*/ > > /*But one must understand the layout of the schema (the document's > architecture used by wsdl which is what you were referring to yesterday > > which is available at */ > > http://schemas.xmlsoap.org/wsdl/ > > > > Your situation listed a site whose net_path was unreachable so I made the > suggestion of contacting them OR > > pulling all those definitions locally... > > Daniels situation is still in development so resolving the namespace > entities would best be accomplished with > > a gradual implementation plan of > > Using Local file system > > Using Local Network > > Using Webserver/AppServer > > In this way you will be able to ascertain the deltas on the port > migrations > > > > HTH, > > Martin-- > > > ********************************************************************* > > This email message and any files transmitted with it contain confidential > > information intended only for the person(s) to whom this email message is > > addressed. If you have received this email message in error, please > notify > > the sender immediately by telephone or email and destroy the original > > message without making a copy. Thank you. > > > > > > > > ----- Original Message ----- > > From: "Ken Campbell" <[EMAIL PROTECTED]> > > To: <[email protected]>; "'Martin Gainty'" < [EMAIL PROTECTED]> > > Sent: Friday, April 07, 2006 11:18 AM > > Subject: RE: Monitor progress of an AXIS SOAP request and response over > http transport > > > > > > > Hi Martin, > > > > > > Excuse me butting in, but I was confused by your reply yesterday. If I > > > understand you correctly you are saying that it is necessary that > namespaces > > > should be network accessible? However, I was under the impression that a > > > namespace was required to be unique, not accessible. Is that not > correct? > > > > > > Regards, > > > Ken > > > > > > -----Original Message----- > > > From: Martin Gainty [mailto: [EMAIL PROTECTED] > > > Sent: 07 April 2006 14:44 > > > To: [email protected] > > > Subject: Re: Monitor progress of an AXIS SOAP request and response over > http > > > transport > > > > > > Good Morning Daniel- > > > > > > I'll re-post the solution that I provided for Ken yesterday > > > 1)First and foremost Go LOCAL! in other words place ALL of your files > > > locally > > > instead of > xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"; > > > use "xmlns:soap=file://fu/bar/fubar/" > > > > > > instead of xmlns:tns="http://www.edp.co.uk/ws/PAF/"; > > > use "xmlns:tns=file://fubar/fubar" > > > > > > > > > instead of xmlns:wsdl=http://schemas.xmlsoap.org/wsdl/ > > > use "xmlns:wsdl=file://fubar/ > > > > > > Now once all your local servers ARE proved to be operational you can > migrate > > > to > > > different servers > > > > > > "xmlns:wsdl=file://FuBarServerIPAddress:/FuBarFolder > > > .. > > > > > > > >
