467,915 Members | 1,150 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,915 developers. It's quick & easy.

Cannot find root element in XML file

Hi all,

I created an XSD to define the structure of an XML file for my project. I
made an XML file linked to the XSD using XmlSpy. The problem is that if I
read the file using .NET XmlDocument and then query for the root element, the
result is always null (1). However if I strip the root element of all
attributes generated by XmlSpy, then there is no problem to find the root
element with .NET XML classes (2).

(1) The XML for which querying root returns null:
Expand|Select|Wrap|Line Numbers
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <IncidentDefinitions xmlns="http://tempuri.org/XMLSchema.xsd"
  3. xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  4. xsi:schemaLocation="http://tempuri.org/XMLSchema.xsd
  5. C:/IncidentDefinitions.xsd">
  6. ....
  7. </IncidentDefinitions>
  8.  
2/ The XML for which querying the root node succeeds:
Expand|Select|Wrap|Line Numbers
  1. <?xml version="1.0" encoding="UTF-8"?>
  2. <IncidentDefinitions>
  3. ....
  4. </IncidentDefinitions>
  5.  
(3) The code in .NET to query for the root element:
Expand|Select|Wrap|Line Numbers
  1. XmlDocument xmlDoc;
  2. xmlDoc.Load( xmlFileName );
  3. XmlNode node = xmlDoc.SelectSingleNode( "IncidentDefinitions" );
  4.  
The thing is that I would very much like to be able to read in XML as in
(1), to allow clients to validate their XML before publishing. For instance
in XmlSpy I can verify the XML content to be valid before publishing it. Of
course verification is no longer necessary once my program tries to read it,
it is assumed that published XML should be valid.

What am I doing wrong in the first part? What can I do to allow both (1) and
(2) in my .NET code?

Kind regards,
--
Tom Tempelaere.
Aug 22 '06 #1
  • viewed: 3087
Share:
16 Replies


TT (Tom Tempelaere) wrote:

<IncidentDefinitions xmlns="http://tempuri.org/XMLSchema.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://tempuri.org/XMLSchema.xsd
C:/IncidentDefinitions.xsd">
....
</IncidentDefinitions>
(3) The code in .NET to query for the root element:
[code]
XmlDocument xmlDoc;
xmlDoc.Load( xmlFileName );
XmlNode node = xmlDoc.SelectSingleNode( "IncidentDefinitions" );
Well if you simply want to access the root element then
xmlDoc.DocumentElement
will do whatever the name of the element is and whatever namespace that
element has (where the namespace in your XML sample is the reason that
your SelectSingleNode does not find the element).
Thus if you need to root element simply use
XmlElement rootElement = xmlDoc.DocumentElement;
I don't think it makes sense to use XPath and SelectSingleNode to look
for something the object model gives as a property.

As for SelectSingleNode to find an element with XPath in a certain
namespace you would need e.g.
XmlNamespaceManager namespaceManager = new
XmlNamespaceManager(xmlDoc.NameTable);
namespaceManager.AddNamespace("pf", "http://tempuri.org/XMLSchema.xsd");
XmlElement rootElement =
xmlDoc.SelectSingleNode("pf:IncidentDefinitions", namespaceManager) as
XmlElement;


--

Martin Honnen --- MVP XML
http://JavaScript.FAQTs.com/
Aug 22 '06 #2
Thanks Martin, that helped.

Kind regards,
--
Tom Tempelaere.

Aug 22 '06 #3
Hi Martin,

I may have cried Victory a little too early. None of your alternative
suggestions works (I should have tested first). See inline for some comment.

"Martin Honnen" wrote:
>
TT (Tom Tempelaere) wrote:

<IncidentDefinitions xmlns="http://tempuri.org/XMLSchema.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://tempuri.org/XMLSchema.xsd
C:/IncidentDefinitions.xsd">
....
</IncidentDefinitions>
(3) The code in .NET to query for the root element:
[code]
XmlDocument xmlDoc;
xmlDoc.Load( xmlFileName );
XmlNode node = xmlDoc.SelectSingleNode( "IncidentDefinitions" );

Well if you simply want to access the root element then
xmlDoc.DocumentElement
will do whatever the name of the element is and whatever namespace that
element has (where the namespace in your XML sample is the reason that
your SelectSingleNode does not find the element).
Thus if you need to root element simply use
XmlElement rootElement = xmlDoc.DocumentElement;
Well to be honest I thought this would solve the problem, but it actually
doesn't. If instead of querying the 'IncidentDefinitions' root element I use
xmlDocument.DocumentElement I still have a problem: I can't find any other
nodes that are in the document.
I don't think it makes sense to use XPath and SelectSingleNode to look
for something the object model gives as a property.

As for SelectSingleNode to find an element with XPath in a certain
namespace you would need e.g.
XmlNamespaceManager namespaceManager = new
XmlNamespaceManager(xmlDoc.NameTable);
namespaceManager.AddNamespace("pf", "http://tempuri.org/XMLSchema.xsd");
XmlElement rootElement =
xmlDoc.SelectSingleNode("pf:IncidentDefinitions", namespaceManager) as
XmlElement;
Doesn't work either. It does return an element, but querying for any of the
documents nodes fails.

It appears as though the attributes that are added by XmlSpy cannot be
parsed correctly by .NET XML framework, or at least confuses it. Or maybe
there is something else still that I'm not doing correct?

In the meanwhile I'll have to ask my clients to not publish any XML files
with attributes for the root element.
--
Martin Honnen --- MVP XML
http://JavaScript.FAQTs.com/
Kind regards,
--
Tom Tempelaere.

Aug 23 '06 #4
"TT (Tom Tempelaere)" wrote:
<IncidentDefinitions xmlns="http://tempuri.org/XMLSchema.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://tempuri.org/XMLSchema.xsd
C:/IncidentDefinitions.xsd">
....
</IncidentDefinitions>
(3) The code in .NET to query for the root element:
[code]
XmlDocument xmlDoc;
xmlDoc.Load( xmlFileName );
XmlNode node = xmlDoc.SelectSingleNode( "IncidentDefinitions" );
Maybe it isn't very obvious, but in the xsi:schemaLocation attribute there
is a space between the two strings in it "http://tempuri.org/XMLSchema.xsd"
and "C:/IncidentDefinitions.xsd". I thought that was not valid for XML to do,
but XmlSpy generates it that way. Could that be the problem?

Kind regards,
Tom Tempelaere.
Aug 23 '06 #5


TT (Tom Tempelaere) wrote:

Well to be honest I thought this would solve the problem, but it actually
doesn't. If instead of querying the 'IncidentDefinitions' root element I use
xmlDocument.DocumentElement I still have a problem: I can't find any other
nodes that are in the document.
Well I have shown you to use an XmlNamespaceManager
>>As for SelectSingleNode to find an element with XPath in a certain
namespace you would need e.g.
XmlNamespaceManager namespaceManager = new
XmlNamespaceManager(xmlDoc.NameTable);
namespaceManager.AddNamespace("pf", "http://tempuri.org/XMLSchema.xsd");
XmlElement rootElement =
xmlDoc.SelectSingleNode("pf:IncidentDefinitions" , namespaceManager) as
XmlElement;
Doesn't work either. It does return an element, but querying for any of the
documents nodes fails.
If those child or descendant elements are in the namespace
http://tempuri.org/XMLSchema.xsd then you again need to use the
namespace manager and you need to use the prefix in your XPath
expressions, that is how XPath works. I don't understand why you claim
the suggested ways don't work if you say they give you the element. If
you then write additional code that does not do what you want then that
additional code needs to be fixed obviously. Use that namespace manager,
use that prefix in your XPath expressions to qualify element names (e.g.
pf:elementname), pass the namespace manager to the SelectSingleNode or
SelectNodes method calls and if you have the proper path then you will
find nodes.
--

Martin Honnen --- MVP XML
http://JavaScript.FAQTs.com/
Aug 23 '06 #6
"Martin Honnen" wrote:
>
TT (Tom Tempelaere) wrote:
Well to be honest I thought this would solve the problem, but it actually
doesn't. If instead of querying the 'IncidentDefinitions' root element I use
xmlDocument.DocumentElement I still have a problem: I can't find any other
nodes that are in the document.

Well I have shown you to use an XmlNamespaceManager
>As for SelectSingleNode to find an element with XPath in a certain
namespace you would need e.g.
XmlNamespaceManager namespaceManager = new
XmlNamespaceManager(xmlDoc.NameTable);
namespaceManager.AddNamespace("pf", "http://tempuri.org/XMLSchema.xsd");
XmlElement rootElement =
xmlDoc.SelectSingleNode("pf:IncidentDefinitions ", namespaceManager) as
XmlElement;

Doesn't work either. It does return an element, but querying for any of the
documents nodes fails.

If those child or descendant elements are in the namespace
http://tempuri.org/XMLSchema.xsd then you again need to use the
namespace manager and you need to use the prefix in your XPath
expressions, that is how XPath works. I don't understand why you claim
the suggested ways don't work if you say they give you the element.
They don't work because from what I understood I only needed the namespace
thingy for querying the root node. The nodes in the XML file aren't qualified
so why would I have to qualify them to look them up?

Makes me wonder how I support both types of XML files, those with attributed
root and those without.

Anyway I don't really understand what it means: "If those child or
descendant elements are in the namespace
http://tempuri.org/XMLSchema.xsd...". I'm far from being an expert in XML
(hence my questions) but I would say that the nodes that I defined in my
schema aren't "child" or "descendant" elements in the namespace
"http://tempuri.org/XMLSchema.xsd". Or am I just not seeing things correctly?
If
you then write additional code that does not do what you want then that
additional code needs to be fixed obviously. Use that namespace manager,
use that prefix in your XPath expressions to qualify element names (e.g.
pf:elementname), pass the namespace manager to the SelectSingleNode or
SelectNodes method calls and if you have the proper path then you will
find nodes.
Well my code that reads in the XML works fine if the root node doesn't have
the attributes, so my code isn't wrong per se.

Anyway, since I'm too noob to understand your answers, I'll go the easy way.
Away with those stupid attributes.
--

Martin Honnen --- MVP XML
http://JavaScript.FAQTs.com/
--
Tom Tempelaere.
Aug 23 '06 #7


TT (Tom Tempelaere) wrote:

They don't work because from what I understood I only needed the namespace
thingy for querying the root node. The nodes in the XML file aren't qualified
so why would I have to qualify them to look them up?
You have not even bothered to show the contents of the root element but
your root element has
<IncidentDefinitions xmlns="http://tempuri.org/XMLSchema.xsd"
which means any child or descendant elements are in that namespace too
unless they have a redeclaration e.g.
<child xmlns="">
to have the element in no namespace or e.g.
<child xmlns="http://example.com/ns1">
to have the element in a different namespace.

See <http://www.w3.org/TR/REC-xml-names/#defaulting>
--

Martin Honnen --- MVP XML
http://JavaScript.FAQTs.com/
Aug 23 '06 #8
Martin,

"Martin Honnen" wrote:
>
TT (Tom Tempelaere) wrote:
They don't work because from what I understood I only needed the namespace
thingy for querying the root node. The nodes in the XML file aren't qualified
so why would I have to qualify them to look them up?

You have not even bothered to show the contents of the root element but
your root element has
<IncidentDefinitions xmlns="http://tempuri.org/XMLSchema.xsd"
which means any child or descendant elements are in that namespace too
unless they have a redeclaration e.g.
<child xmlns="">
to have the element in no namespace or e.g.
<child xmlns="http://example.com/ns1">
to have the element in a different namespace.

See <http://www.w3.org/TR/REC-xml-names/#defaulting>
Oki, thanks for the information.

What I notice is that using the XPath expressions for the XML file where the
root has an xmlns attribute, doesn't work for XML files where the root has no
xmlns attribute (and vice versa). Is there any easy way to support both using
the same XPath expressions? Or would I have to force my clients to either add
the xmlns attribute or ommit it?

Another question since you seem to be an expert on XML and related stuff.
What would you ask your clients to supply as XML files: with or without the
xmlns attribute? I'm rather unaware of what is usually done because I have
little experience in these matters.
--

Martin Honnen --- MVP XML
http://JavaScript.FAQTs.com/
Thanks,
--
Tom Tempelaere.
Aug 24 '06 #9
"TT (Tom Tempelaere)" <_|\|_0$P@|/\|titi____AThotmailD.Tcom|/\|@P$0_|\|_>
wrote in message news:8B**********************************@microsof t.com...
Martin,

"Martin Honnen" wrote:
>>
TT (Tom Tempelaere) wrote:
They don't work because from what I understood I only needed the
namespace
thingy for querying the root node. The nodes in the XML file aren't
qualified
so why would I have to qualify them to look them up?

You have not even bothered to show the contents of the root element but
your root element has
<IncidentDefinitions xmlns="http://tempuri.org/XMLSchema.xsd"
which means any child or descendant elements are in that namespace too
unless they have a redeclaration e.g.
<child xmlns="">
to have the element in no namespace or e.g.
<child xmlns="http://example.com/ns1">
to have the element in a different namespace.

See <http://www.w3.org/TR/REC-xml-names/#defaulting>

Oki, thanks for the information.

What I notice is that using the XPath expressions for the XML file where
the
root has an xmlns attribute, doesn't work for XML files where the root has
no
xmlns attribute (and vice versa). Is there any easy way to support both
using
the same XPath expressions? Or would I have to force my clients to either
add
the xmlns attribute or ommit it?
The presence or absence of the xmlns attribute mean different things. With
xmlns="urn:something", you're saying that all of the elements and attributes
in the document are in the namespace "urn:something". For example, in:

<root xmlns="urn:something" id="1"/>

"root" really means {urn:something}:root and "id" means {urn:something}:id.

When you're doing an XPath lookup for "root", you're looking for {}:root,
which is a totally different thing.

So, it's not that your clients have to either add or omit the xmlns
attribute - it's that they have to send you documents with the elements and
attributes in the correct namespace. If you've defined things so that your
elements aren't in a namespace, then they shouldn't send you elements which
are in a namespace. If you'ev defined things (properly), so that your
elements are in a namespace, then your clients have to send you documents
where the elements are in that namespace.

John
Aug 24 '06 #10
Hi John,

"John Saunders" wrote:
"TT (Tom Tempelaere)" <_|\|_0$P@|/\|titi____AThotmailD.Tcom|/\|@P$0_|\|_>
wrote in message news:8B**********************************@microsof t.com...
Martin,

"Martin Honnen" wrote:
>
TT (Tom Tempelaere) wrote:

They don't work because from what I understood I only needed the
namespace
thingy for querying the root node. The nodes in the XML file aren't
qualified
so why would I have to qualify them to look them up?

You have not even bothered to show the contents of the root element but
your root element has
<IncidentDefinitions xmlns="http://tempuri.org/XMLSchema.xsd"
which means any child or descendant elements are in that namespace too
unless they have a redeclaration e.g.
<child xmlns="">
to have the element in no namespace or e.g.
<child xmlns="http://example.com/ns1">
to have the element in a different namespace.

See <http://www.w3.org/TR/REC-xml-names/#defaulting>
Oki, thanks for the information.

What I notice is that using the XPath expressions for the XML file where
the
root has an xmlns attribute, doesn't work for XML files where the root has
no
xmlns attribute (and vice versa). Is there any easy way to support both
using
the same XPath expressions? Or would I have to force my clients to either
add
the xmlns attribute or ommit it?

The presence or absence of the xmlns attribute mean different things. With
xmlns="urn:something", you're saying that all of the elements and attributes
in the document are in the namespace "urn:something". For example, in:

<root xmlns="urn:something" id="1"/>

"root" really means {urn:something}:root and "id" means {urn:something}:id.

When you're doing an XPath lookup for "root", you're looking for {}:root,
which is a totally different thing.

So, it's not that your clients have to either add or omit the xmlns
attribute - it's that they have to send you documents with the elements and
attributes in the correct namespace. If you've defined things so that your
elements aren't in a namespace, then they shouldn't send you elements which
are in a namespace. If you'ev defined things (properly), so that your
elements are in a namespace, then your clients have to send you documents
where the elements are in that namespace.

John
Thanks for that John. So the way I understand is that if I define my root in
XSD as follows:

<?xml version="1.0" encoding="utf-8"?>
<xs:schema targetNamespace="http://tempuri.org/XMLSchema.xsd"
xmlns="http://tempuri.org/XMLSchema.xsd"
xmlns:mstns="http://tempuri.org/XMLSchema.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified">
<xs:element name="IncidentDefinitions">
...definitions etc...
</xs:schema>

Then this schema basically sais that any element and types that it defines
become members of the "http://tempuri.org/XMLSchema.xsd" namespace because of
the targetNamespace attribute of the xs:schema element? Or is it the xmlns
attribute (the value of both in the XSD is the same)?

And, that any XML document that is to conform with the schema, has to
attribute the root with xmlns attribute referring to that namespace?

Kind regards,
--
Tom Tempelaere.
Aug 25 '06 #11
"TT (Tom Tempelaere)" <_|\|_0$P@|/\|titi____AThotmailD.Tcom|/\|@P$0_|\|_>
wrote in message news:A9**********************************@microsof t.com...
Hi John,

"John Saunders" wrote:
>"TT (Tom Tempelaere)" <_|\|_0$P@|/\|titi____AThotmailD.Tcom|/\|@P$0_|\|_>
wrote in message
news:8B**********************************@microso ft.com...
Martin,

"Martin Honnen" wrote:

TT (Tom Tempelaere) wrote:

They don't work because from what I understood I only needed the
namespace
thingy for querying the root node. The nodes in the XML file aren't
qualified
so why would I have to qualify them to look them up?

You have not even bothered to show the contents of the root element
but
your root element has
<IncidentDefinitions xmlns="http://tempuri.org/XMLSchema.xsd"
which means any child or descendant elements are in that namespace too
unless they have a redeclaration e.g.
<child xmlns="">
to have the element in no namespace or e.g.
<child xmlns="http://example.com/ns1">
to have the element in a different namespace.

See <http://www.w3.org/TR/REC-xml-names/#defaulting>

Oki, thanks for the information.

What I notice is that using the XPath expressions for the XML file
where
the
root has an xmlns attribute, doesn't work for XML files where the root
has
no
xmlns attribute (and vice versa). Is there any easy way to support both
using
the same XPath expressions? Or would I have to force my clients to
either
add
the xmlns attribute or ommit it?

The presence or absence of the xmlns attribute mean different things.
With
xmlns="urn:something", you're saying that all of the elements and
attributes
in the document are in the namespace "urn:something". For example, in:

<root xmlns="urn:something" id="1"/>

"root" really means {urn:something}:root and "id" means
{urn:something}:id.

When you're doing an XPath lookup for "root", you're looking for {}:root,
which is a totally different thing.

So, it's not that your clients have to either add or omit the xmlns
attribute - it's that they have to send you documents with the elements
and
attributes in the correct namespace. If you've defined things so that
your
elements aren't in a namespace, then they shouldn't send you elements
which
are in a namespace. If you'ev defined things (properly), so that your
elements are in a namespace, then your clients have to send you documents
where the elements are in that namespace.

John

Thanks for that John. So the way I understand is that if I define my root
in
XSD as follows:

<?xml version="1.0" encoding="utf-8"?>
<xs:schema targetNamespace="http://tempuri.org/XMLSchema.xsd"
xmlns="http://tempuri.org/XMLSchema.xsd"
xmlns:mstns="http://tempuri.org/XMLSchema.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<xs:element name="IncidentDefinitions">
...definitions etc...
</xs:schema>

Then this schema basically sais that any element and types that it defines
become members of the "http://tempuri.org/XMLSchema.xsd" namespace because
of
the targetNamespace attribute of the xs:schema element? Or is it the xmlns
attribute (the value of both in the XSD is the same)?

And, that any XML document that is to conform with the schema, has to
attribute the root with xmlns attribute referring to that namespace?
You've got it. It's the targetNamespace which defines these elements in that
namespace. It's the xmlns on the insance document which specifies that those
elements refer to the same ones you defined - which is what you probably had
in mind.

Also, keep in mind that there is more than one way to place instance
elements into your namespace. For instance, <IncidentDefinitions
xmlns="http://tempuri.org/XMLSchema.xsd"/or <xxx:IncidentDefinitions
xmlns:xxx="http://tempuri.org/XMLSchema.xsd"/or <yyy:IncidentDefinitions
xmlns:yyy="http://tempuri.org/XMLSchema.xsd"/are all the same thing.

John
Aug 25 '06 #12
Thanks John and Martin for helping me understand things.

Kind regards,
--
Tom Tempelaere.
Aug 25 '06 #13
Hi,

I have one final question about these namespaces, hope you don't mind.

What if my XSD root read like:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
.....
</xs:schema>

Does this schema also imply that the elements of an XML document based on
that XSD are in a specific namespace? Or does this schema define elements
that are in the empty namespace?

Kind regards,
--
Tom Tempelaere.

Aug 25 '06 #14
"TT (Tom Tempelaere)" <_|\|_0$P@|/\|titi____AThotmailD.Tcom|/\|@P$0_|\|_>
wrote in message news:91**********************************@microsof t.com...
Hi,

I have one final question about these namespaces, hope you don't mind.

What if my XSD root read like:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
.....
</xs:schema>

Does this schema also imply that the elements of an XML document based on
that XSD are in a specific namespace? Or does this schema define elements
that are in the empty namespace?
Since it doesn't have a target namespace, the elements are defined in the
empty namespace, which is generally not a good idea.

John
Aug 25 '06 #15
"John Saunders" wrote:
"TT (Tom Tempelaere)" <_|\|_0$P@|/\|titi____AThotmailD.Tcom|/\|@P$0_|\|_>
wrote in message news:91**********************************@microsof t.com...
Hi,

I have one final question about these namespaces, hope you don't mind.

What if my XSD root read like:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
.....
</xs:schema>

Does this schema also imply that the elements of an XML document based on
that XSD are in a specific namespace? Or does this schema define elements
that are in the empty namespace?

Since it doesn't have a target namespace, the elements are defined in the
empty namespace, which is generally not a good idea.

John
Hi,

Oki thanks. I will have to read some more about why those namespaces are
really necessary and in what circumstances.

Kind regards,
--
Tom Tempelaere.
Aug 25 '06 #16
"TT (Tom Tempelaere)" <_|\|_0$P@|/\|titi____AThotmailD.Tcom|/\|@P$0_|\|_>
wrote in message news:CC**********************************@microsof t.com...
"John Saunders" wrote:
>"TT (Tom Tempelaere)" <_|\|_0$P@|/\|titi____AThotmailD.Tcom|/\|@P$0_|\|_>
wrote in message
news:91**********************************@microso ft.com...
Hi,

I have one final question about these namespaces, hope you don't mind.

What if my XSD root read like:

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
.....
</xs:schema>

Does this schema also imply that the elements of an XML document based
on
that XSD are in a specific namespace? Or does this schema define
elements
that are in the empty namespace?

Since it doesn't have a target namespace, the elements are defined in the
empty namespace, which is generally not a good idea.

John

Hi,

Oki thanks. I will have to read some more about why those namespaces are
really necessary and in what circumstances.
This part is simple.

If you will only ever be dealing with one XML vocabulary, and if these
simple XML files you're dealing with will never be used anywhere else, then
don't use namespaces.

But the whole point of XML is universality. XML is data and program and
everything in between. XML can be consumed by XML, sent to web services, and
all sorts of things you've never considered. As a crazy example, I have code
which manipulates XML to produce a schema which is then made into part of
the WSDL for a web service which is then sent blocks of XML as parameters!

Namespaces simply allow my node called "root" to be different from your node
called "root", and in fact your "root" today, for application "a" to be
different from your own node "root", in application "b", tomorrow. They are
a:root and b:root, and they are totally different things.
John
Aug 25 '06 #17

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

1 post views Thread by Brian | last post: by
5 posts views Thread by Paul Nations | last post: by
2 posts views Thread by PeterW | last post: by
28 posts views Thread by Andy Dingley | last post: by
3 posts views Thread by Lord0 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.