Good Evening Jeff-
would you be prohibited from storing the local url (which resolves the remote url) on a local file?
Many Thanks for your thoughtful response,
Martin--

"As far as the laws of mathematics refer to reality, they are not certain, as far as they are certain, they do not refer to reality." - Albert Einstein ----- Original Message ----- From: "Jeff Greif" <[EMAIL PROTECTED]>
To: <[email protected]>; "Martin Gainty" <[EMAIL PROTECTED]>
Sent: Friday, April 07, 2006 8:22 PM
Subject: Re: Monitor progress of an AXIS SOAP request and response over http transport


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
> > ..
> >
> >


Reply via email to