I am studying SOAP web services and I am really new to Web Services. In the WSDL I got a little confused with regards to the targetNamespace element in the definition and the namespace included in the xsd:schema.
<definitions .... targetNamespace=" " >
<xsd:schema>
<xsd:import namespace=" " schemaLocation=""/>
</xsd:schema>
What does it mean by these two elements and I searched through many articles in the web and I was unable to clearly identify this. Can anybody please explain me?
Do these two get same values?
The target namespace in the WSDL file will be the name space associated with the SOAP service itself. For example we have a customer service the namespace would be something like http://www.acme.com/Customer/V1/CustomerService.
The XSD imports section is where you specify the namespace of the XSD you are about to import. A XSD file will contain the data that the service will send i.e. it contains the object definitions that will be serialized into XML and sent up and down as the request and responses. A XSD can also contain the operations that the WSDL will expose.
A WSDL can import one or more XSD files and each XSD will have its own namespace. A XSD will contain a namespace such as:
http://www.acme.com/Customer/V1/GetCustomerRequest for the GetCustomerRequest this will define the data structure of the GetCustomerRequest operation.
http://www.acme.com/Customer/V1/CustomerObject for the CustomerObject this will define the data structure of the CustomerObject.
Namespaces are a bit like Java packages they just allow you to define a hierarchy of objects. One important thing to understand is that you might have two Customer objects one that belongs to your sale system and one that belong to your CRM system for example. By placing these in separate namespaces you will be able to use both Customer object in the same service as long as they have unique namespaces.
Normally these namespaces will form part of the SOA catalog as well and defining them will be part of your SOA governance standards. They are important if you want to do SOA successfully.
I'll explain using Java analogy.
Namespace is like Java packages. Each xml element is in a namespace. Providing a targetNamespace means that all elements (and types) defined within are in that namespace. It's similar to that all Java classes are within the package.
The xsd being imported will have its own target namespace that would mean that all elements in the xsd will be in the namespace defined.
The import in the wsdl is like providing a java import specifying the package.
I hope I am clear and helpful :D.
targetNamespace is like package declaration in java, used in schema creation
namespace is like package import in java, this is generally use for re-using one schema inside another schema.
targetNamespace is an XML Schema "artifact".User-defined data types may have possibility of name clashes when we work with different team. This an attribute of schema element defines namespace i.e. package. By convention we use URI/URLs, but we could use any string..
<?xml version="1.0" ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="namespace">
...
</xs:schema>
for example:
xsi:schemaLocation="http://www.springframework.org/schema/mvc http://www.springframework.org/schema/beans/spring-mvc.xsd" xmlns:mvc="http://www.springframework.org/schema/mvc"
// or if the schema exist in current directory we can declare as follows
xsi:schemaLocation="http://www.springframework.org/schema/mvc spring-mvc.xsd" xmlns:mvc="http://www.springframework.org/schema/mvc"
//for import xml schema
<xsd:import schemaLocation="http://localhost:9999/ws/hello?xsd=1" namespace="http://ws.peter.com/"/>
Note: xsi:schemaLocation mean the namespace and URL are separated with whitespace. And xmlns:mvc mean the namespace http://www.springframework.org/schema/mvc define as mvc alias.
namespace analogy:
+---------+--------------------------------------------------------+------------------------------+------------------------+
| Context | Name | Namespace identifier | Local name |
+---------+--------------------------------------------------------+------------------------------+------------------------+
| Path | /home/user/readme.txt | /home/user (path) | readme.txt (file name) |
| XML | xmlns:xhtml="http://www.w3.org/1999/xhtml"<xhtml:body> | http://www.w3.org/1999/xhtml | body |
| Java | java.util.Date | java.util | Date |
+---------+--------------------------------------------------------+------------------------------+------------------------+
for more details
Related
I'm using xjc (jaxb2-maven-plugin) to generate my POJOs from several XSD files. Not surprisingly, there are class conflicts if I put all my generated files into one package. By default xjc will use the namespace as a package name.
Ex:
namespace: "https://analysiscenter.domain.com/schema/4.0/sandboxlist"
becomes package: https.analysiscenter_domain_com.schema._4_0.sandboxlist
I realize that I can use xjc:bindings to specify individually which namespace becomes which package, but that becomes quite tedious. Is there any way to specify rules or regexs for the bindings for all xsds?
Ex: namespace ./schema/(.)/(.*) becomes package: myDefaultPackage.$1.$2
Ex something like the following:
<jaxb:bindings schemaLocation="*.xsd" node="/xsd:schema[#value=.*/schema/(.*)/(.*)">
<jaxb:schemaBindings>
<jaxb:package name="com.domain.$1.$2"/>
</jaxb:schemaBindings>
</jaxb:bindings>
Is there any way to specify rules or regexs for the bindings for all xsds?
No, you can't use regexes or similar. But I think you should be able to write an own implementation of the com.sun.xml.bind.api.impl.NameConverter and register it in com.sun.tools.xjc.Options.setNameConverter(...) via XJC plugin.
I'm writing a program which fetches a WSDL and any imported files, then saves them to a single directory. What I want to do as part of this is to flatten the file structure so there's just one directory which contains all the files referenced by the WSDL or referenced by its referenced files. So I need to go into each file and wherever there's an import, I need to strip the path out of the name. Here's an example:
<xsd:import schemaLocation="xsds/Currency.xsd" namespace="urn:example.com:enterprise:schemas:reference:currency">
</xsd:import>
So the import above references the file xsds/Currency.xsd and I want to just extract Currency.xsd from this. I can get the content of this attribute with an XPath expression to match the tag like so:
//*[local-name()='import']/#schemaLocation
However, there are probably other types of tags where a WSDL or it's referenced xsds might import files which this XPath expression won't match. What are the other tags or field names I might need to match on so I don't miss any files?
You might want to use
//#schemaLocation
which would catch all schemaLocation attributes independent of where they occur.
Elements that contain the schemaLocation attributes in the XSD namespace:
import
include
redefine
You should be aware that in the XMLSchema-instance namespace, the qualified schemaLocation attribute will contain space separated pairs where each even-numbered component is a location (the odd-numbered items are namespaces).
What does a namespace do in XSLT when a url is provided such as:
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
does this attempt to make a connection to the internet?
No; it just so happens that the specification for XML Namespaces (see W3C XSL Namespace specifications) are URI's.
They work in exactly the same way that namespaces in other languages do; they help uniquely identify things with the same names but in different contexts.
You can prove that no attempt is made to retrieve the resource by using a HTTP Monitor on your machine while loading or using the XSL Transformation - this answer has many good suggestions.
No.
Whatever the namespace is in a xsd, an xslt or any other xml file, there is no internet request.
The namespace is used to qualified your xml element.
When you conduct an XSLT transformation, the XSLT engine validates the XSLT file. It performs many checks, such as the root element being named stylesheet, etc. The engine must also be able to discern literal result elements (like <table>) from XSLT-specific elements (like <xsl:stylesheet>).
An element is recognized as XSLT-specific when it resides in the XSLT namespace. The value of the URI you posted (http://www.w3.org/1999/XSL/Transform) is simply a convention that makes it clear we're talking about XSLT. The prefix being defined (xsl) is the prefix used in the XSLT file to qualify the XSLT elements. You can use another prefix if you choose, provided you map it to the XSLT namespace.
Note that it's actually just a URI (an identifier), not a URL (a locator). There is no HTTP request to locate anything, it just identifies an abstract concept (in this case "XSLT").
XSL requires this at the top of every stylesheet:
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
and throws an error if the url in the namespace is not exactly right.
Today, "http://www.w3.org/1999/XSL/Transform" is offline. I cannot run any transformations. The transformation hangs and then returns "unexpected end of file" when the net request times out. If I change the URL in the namespace declaration to a random URL, the transformation fails with an error telling me that "http://www.w3.org/1999/XSL/Transform" is the required xsl namespace.
So how do I work around W3's site being down?
Using xmlns:something="..." declares an XML namespace. Such a namespace is merely a string, something that will help to attribute a unique meaning to element names like template or href, making sure multiple XML-based languages can be used in a single document without creating confusion as to its meaning.
Some of those namespaces are reserved for use by the W3C. The XSLT namespace is one of those. A proper XSLT processor will check if a stylesheet declares the correct namespace to make sure there can be no incorrect interpretation. The root element of the stylesheet should be in that XSLT namespace.
For an actual namespace value, you'd usually have a URI (and most often a URL) since that's normally a good unique identifier. However, this should never be used to actually resolve to any online resources during XML processing. Whereas HTTP URLs are normally treated in a case-insensitive manner and may make use of URL encoding for characters (e.g. space becomes %20), such resolution or equality of URLs is not checked in XML namespace processing. A namespace in XML is nothing but a string that's always checked in its exact form, casing and everything.
So if an XSLT processor complains that some resource at a URL cannot be found, then either it's doing something it shouldn't do, or the problem has nothing to do with namespace processing.
You're using Saxon, which most definitely isn't a processor that doesn't understand the concept of a namespace. Its father is Michael Kay who is also responsible for the XSLT 2.0 spec. But Saxon does support schema-aware XSLT processing. If a document specifies a schema location, then a processor using this for validation would actually use that location to get the schema. That's the difference with a namespace. DTDs and XML Schema locations can definitely result in network activity.
So I advise you to check if...
the XML uses a DTD with external definitions and whether those are available;
the XML specifies a schema location and whether that location can be reached;
the stylesheet makes use of a schema or some other external resource and whether that's available.
Once you've found the cause, look into the use of XML catalogs in conjunction with the processor. An XML catalog will allow you to use local resources if they can't be resolved from their URIs.
Simple answer: The http://www.w3.org/1999/XSL/Transform isn't a URL, it's just a string. If W3C had decided, there's no reason it couldn't have been 'ThisIsAnXsltStylesheet'. By convention, they usually resemble URL's, but this isn't required.
So, the fact that there's nothing at that URL isn't relevant to why your stylesheet is failing, and certainly won't be the cause. Logically speaking, if that were the case, then nobody without an internet connection would ever be able to use XSLT, and w3c's servers would be seriously overworked.
I'd recommend adding the first few lines of your XSLT into your question; it might shed some light on where your problem really is.
I am using gSOAP to create C++ code from a WSDL document. The problem is gSOAP is giving me errors when I run the wsdl2h tool on my WSDL file. The errors are all related to namespace issues. For example
Warning: could not find element 'GetRPCMethods' type '"http://www.broadband-forum.org/cwmp/cwmp-1-2.xsd":GetRPCMethods' in schema urn:tr069
I have pasted the namespace definitions and an example of how they are used below. Anyone know where I am going wrong?
urn:tr069 is supposed to refer to the current document.
<s0:definitions
name="tr069"
xmlns:s0="http://schemas.xmlsoap.org/wsdl/"
xmlns:s1="urn:tr069"
xmlns:s2="http://schemas.xmlsoap.org/wsdl/soap/"
targetNamespace="urn:tr069">
<s0:types>
<xsd:schema
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="urn:tr069"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
xmlns:xsd1="http://www.broadband-forum.org/cwmp/cwmp-1-2.xsd"
targetNamespace="urn:tr069">
<xsd:import namespace="urn:dslforum-org:cwmp-1-2" schemaLocation="cwmp-1-2.xsd" />
<xsd:element name="GetRPCMethods" type="xsd1:GetRPCMethods" />
</xsd:schema>
</s0:types>
<s0:message name="GetRPCMethods">
<s0:part element="s1:GetRPCMethods" name="GetRPCMethods" />
</s0:message>
</s0:definitions>
I have a few other questions, as I understand it the target namespace does not have to point to a real location, it is just a convention for pointing to the current document, Is this correct? Also in cwmp-1-2.xsd there is an element called GetRPCMethods which contains a sequence containing another element. Is it best practice to use this whole element(GetRPCMethods) as a part for a message as I have above or should I define the specific parts of GetRPCMethods in the message?
Thank you.
The problem was the elements defined in the <schema> tag. First I removed all the defined elements inside the <schema> tag because they were completely unnecessary anyway. Then I changed the namespace of the elements in the message parts from s1 to xsd1 to use the elements in cwmp-1-2.xsd instead of the ones I defined in the <schema> tag.
As for my other questions, the targetNameSpace does not have to point to a real uri, it is just a name for the namespace of this document. For my second question, I think it is probably best and easiest to use the whole schema element as the part for the message.
I notice that
<xsd:schema>
doesn't have a closing tag? Is the wsdl a well-formed XML Document?
Targetnamespace is the namespace of the instance document ie., the one for SOAP:Envelope.
The error message says what's wrong, you don't have a definition of xsd1:GetRPCMethods, is this somewhere defined?
s1:GetRPCMethods is looked up -> s1 is found to be urn:trn069 -> urn:trn069 is not unique which might be a problem -> urn:trn69 defines the element, GetRPCMethods which is of type xsd1:GetRPCMethods -> this type is not found.
I'm not sure if it is valid to use the same URI for the targetNamespace. Maybe that's causing additional problems.