The WebService Namespace (as identified by the compiler attribute) looks
like a URL, but does not need to represent (in its entirety) a REAL
browseable resource on your organization's web server.  It is not meant to
reflect the location the webservice is being served from and should remian
static.

It is used in conjunction with the XML data that will be sent to and
returned from the WebService.  Since XML tags can be made up, we need a way
to "group" tags into logical containers.  Just like .NET makes use of
Namespaces to group, organize and prevent naming collisions of classes, XML
uses Namespaces to do the same for XML markup.  The format of an XML
namespace, however, takes the form of something that we know to be unique to
us (because if we just made up a word for our namespace name, it is possible
that others could inadvertently come up with the same term.  So, we make a
namespace name from our company or organization's URL.  Why in the world
would widget.com use "http://acme.com" in their namespace names?  Well, they
wouldn't.  Since our domain name is guaranteed to be unique in the world, we
START (key word here - START) our namespace off with our domain name.  But
then, we add more to that (and this is the part to be clear on) that is
completely made up.  So the whole URL becomes something that may not really
exist on the web, but that doesn't matter, because we're not trying to
browse to that address.  We're just trying to identify our XML markup in a
way that no one else would.

For example:   http://wallStreetMillionaires.com/services/stockQuote may
contain an XML tag called "string" and
http://dotComMillionaires.com/services/realTimeQuote might also contain an
XML tag called "string", but we'd now have a way to know who's "string" is
who's.  But, we don't need to browse to either address, nor is our code
going to attempt to resolve those addresses.  They're just names for our
tags.

Hope this helps.

-Scott