Namespaces are a way to separate or class the elements in a document that is composed of elements from multiple schema (different types of XML file)

You don't have to create schema documents; in essence a schema document (like the one at http://www.w3.org/2001/12/soap-envelope) just defines which elements can have which attributes/children. They do not define processing rules very thoroughly, and at the moment, can only really be seen as a strict 'template' definition for a nodeset representing the namespace.

Exactly "how" a processor interprets a namespace seems to be quite an arbitrary thing; most XML technology processors perform set tasks based on document structure/order, and perhaps only interpret namespaces by looking at a list of which URI schemas relate to their specific task(s). A good (but probably slow) parser for a technology could in theory, download the namespace schema and use it to validate the elements within its namespace. A developer could probably take that further by reading 'lookups'/references from the schema and using them programatically within a parser's processing job to control the parser's activity.

In theory; a good SOAP parser should be able to understand:


In practise, only new &conformant parsers would be able to deal with this. Some parsers may only respond (in a defined way) to elements that start with their prefered namespace regardless of where the namespace is sourced from via an xmlns attribute.

The 'm' namespace by the way; has just been used as an example in that document. You'll see that there is no schema document at that location; wheras for the SOAP namespace; there is one (use View Source in your browser to see it).

You can always use the default namespace (element's with no prefix: part) if you're mixing a single custom schema with a 'technology' schema (like SOAP or XSLT),

In XHTML documents, the default namespace is usually set to the XHTML namespace... I suppose you should define the default namespace in the root node of any document.

Providing the <GetPrice> node is always going to be the root node; this would be correct:


BUT! for the most part; not defining the default namespace is usually OK. Especially if you don't know where that node is going to end up within a larger document.

First of all thanks for replying to my post. So if I understand you correctly,

<a: node1>
...........
<b:node2>
.........
</node2>
<node1>

node1 will follow the rules described by page a. Where as node2 will follow rules from page b.

And the purpose of the m: before <getPrices> is to make sure that only the <Item> node can be placed inside the <getPrice> node. Am I getting this right?

They wont neccessarily follow the rules, but they are in the same namespace and each namespace could be associated with a schema document; the parser reading that document could chose to enforce the rules of that schema, and it's probably better to assume that every parser will enforce those rules; and it certainly couldn't hurt to use 'real' schema documents rather than dead links for the namespace address.

It's more important that the namespaces separate the two types of data in that document, and that namespaces generally (although not officially) imply that a group of nodes could be processed by a different technology than other nodes in the document.

Nope; the purpose of the m: before getPrices and item is to place those nodes to a namespace. Whether or not a parser looks at the schema relating to m: (or enforces its rules) is down to the parser, and what the parser does. An m: parser might be particularly interested in the latest m: schema; but an XSL parser wouldn't be interested atall.

SOAP perhaps uses namespaces more than other technologies, because there seem to be alot of technologies that can be used within a single SOAP document.

Perhaps this document will be more helpful than me with regard to SOAP specifically:

http://www.awprofessional.com/articl...&seqNum=2&rl=1

So, the purpose of m: is to seperate a group of nodes from the other nodes so it will be easier to find and work with all the m: nodes. Or least thats what I gathered from the the article. Am I getting close?

You're getting closer certainly; and from a parser's perspective that's pretty much exactly how a namespace works.

From a developers perspective, although the namespace does visually separate those nodes from the surrounding document, it's more that we're highlighting those nodes as being a specific grouping so that a parser could decide to treat them differently to how it may treat nodes in another (different) namespace.

I plan on learning to build web services using java. Can you tell me what softwares I need? Is the regular jdk 1.6.0 that I have installed sufficient? Or do I need a different version?

By the way I am trying follow instruction from a book and tomcat is installed twice in the book's example. First its installed in the home folder as a servlet !container! and then its installed in the /usr/local/ folder as a web server. Is this a typo? Should I follow these directions?

These questions will definately get better answers in the Java forum.

For the first one; it depends what kind of web application you're developing. You have the standard JDK which is fine for web-deployed desktop applications but not ideal because you need to create client-server pairs and/or get past security rules, You have the mobile device JDK (J2ME) which will probably be very web-orientated these days, and things like JSP for 'webpage applications' which you're probably considering if you want to use Tomcat...

For the second one; I imagine that the installation in a home directory is for a modifiable folder, and the installation in the /usr/ folder is for program binaries. Don't take that as an authoritative answer though... I haven't ever used JSP or Tomcat; I'm sure someone who has will be more helpful; and there's a large chance there'll be more of them watching the Java forum than the XML forum.

=)