Data Access Worldwide Knowledge Base
Article Text
QUESTION:
Not knowing exactly why, I set the targetNamespace=http://mysystems.com/WebServices. I set it to the properties of my WebService object. Since http://mysystems.com/WebServices does not really exist, should I have an empty namespace instead?
Should I use something like
Move "" to sNameSpace
and then use the sNameSpace variable?
ANSWER:
Setting the namespaceURI is not quite the same thing (although often the namespaceURI happens to be the same namespace used by the xml document).
The way to think of it, is that an XML document without namespaces is like calling everyone by their first name. It is easy to start this way but at some point this gets clumsy. Adding the namespace adds the last name. The whole point of a namespace is to create element tags (namespace_URI + element name) that are unique.
Most of the time when you start, you end up thinking "well for my application I don't care if my tags are unique ... I know what to do with them". Mostly that's true, but it can come back and trouble you. It is of course entirely up to you do come up with a namespace that is unique (e.g. http://accordsystems.com/WebServices). If you do that and you control the names of your elements (e.g. Customer, Name, Address), you've got a unique name. A good way to make sure your namespace is unique is to use a URL address since they must be unique. You can then add anything you want to URL address to create a good namespace (e.g. /WebServices, /WebServices/App1, /hey-this-is-my-area).
What always confused me was that the namespace did not have to be a real address out there on the web because it sure looks like it is an address and every editor sure wants to make it look like a hyper-link. A namespace tells you nothing about any URL location - it's just a name.
Here's the trick. Setting your target namespace does not set the namespace in your xml document. The xml document that you create is a stand-alone document and it may have its own namespace. If it does, you need to define the namespaces in your document when you add each XML node. If you don't do this, your XML document would not have namespaces at all, which is a perfectly valid thing to do. However, with a tiny bit of extra work, you can use namespaces and will be creating something that will be more robust.
If you look at our example, you will see a line that defines the namespace for the document as:
Move "http://www.dataacess.com/Test/CustomerList" to sNameSpace
and then we use this whenever we create an element. For example:
Get CreateDocumentElementNS Of hoXML sNameSpace "CustomerList" To hoRoot
or
Send AddElementNS Of hoEle sNameSpace "Name" sName
This creates the xml document with the proper namespaces.
Now, if you use namespaces to create the document, your client will have to use namespaces when it parses the document. You can look at our web service client example and see stuff like:
Move "http://www.dataacess.com/Test/CustomerList" to sNs
Get ChildElementNS of hoRoot sNs "Customer" to hoCust
While hoCust
Get ChildElementValueNS of hoCust sNs "Name" to sName
In your example you could use the same value you used for your TargetNamespace (http://accordsystems.com/WebServices) or you could create yet another unique namespace name (e.g. http://accordsystems.com/WebServices/MyName1).
As I said, this is not required and prior to VDF10 we pretty much glossed over the whole subject of namespaces. Until you get a handle on this, it is a pretty confusing topic. In the meantime, if you just use the server and client transfer samples we have as cookbook examples, you can probably make good progress. We also have docs on a lot of this in the Help.
Contributed By:
John Tuohy
Company: Data Access Worldwide
Web Site: http://www.dataaccess.com
Email this Article
Email this Article to a Colleague
Send Feedback on this Article to Data Access Worldwide
Copyright ©2010 Data Access Corporation. All rights reserved.
| The information provided in the Data Access Technical Knowledge Base is provided "as is" without warranty of any kind. Data Access Corporation disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Data Access Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Data Access Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply. |