A lot of the code in NAnt that uses XPath could really be rewritten so that
it doesn't without much trouble at all. For example, most of the
SelectSingleNode calls are just getting attributes which could just as
easily (and possibly even more efficiently) be gotten be casting an XmlNode
to XmlElement and using the GetAttribute method. These calls aren't actually
affected by this problem since the attributes aren't qualified but it might
be worth it to remove those anyways.
There are some other SelectSingleNode calls that get a named child element.
These could use the indexer on XmlNode. The project element is always the
document element so we could use XmlDocument.DocumentElement to get at that.
But the question is really do we want to require that NAnt elements be
namespace qualified? I can see arguments for both sides but am currently
leaning towards no.
It's unfortunate that VS.NET requires a targetNamespace in XSDs in order to
use IntelliSense especially since XSDs are perfectly capable of describing
documents that make no use of namespaces. I ran into this (and probably the
other problems you mentioned) just yesterday for a different project. It's
frustrating because VS.NET is _sooo_ close to being perfect but not close
enough to where you can actually use it.
Jason
- Original Message -
From: Scott Hernandez [EMAIL PROTECTED]
To: 'Ian MacLean' [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Wednesday, April 17, 2002 2:38 PM
Subject: RE: [nant-dev] nant.xsd sample
Yeah, that is the basic problem. The xpath queries use no context by
default; you could think of it like the empty namespace. So we have to
provide context for queries. Here is how it would have to work.
XmlNamespaceManager nm = new XmlNamespaceManager(new
NameTable());
nm.AddNamespace(nant,nantNameSpaceURI); //namespace prefix
XmlNode node = doc.SelectSingleNode(nant:project, nm); //
w/prefix
Not such a big change, but one that will affect all xpath queries.
I think we can detect if a namespace is used on the project element and
use that for our queries. But it will require that in all our xpath
queries we use a pre-defined prefix (like nant:).
And in the case where no namespace is specified, we can add one to the
document (once it has been loaded) so queries still work.
I expect the types of build files that will be supported will have to be
in one of the three following forms:
1.) No namespace
project/
2.) default namespace provided
project xmlns=nantNameSpaceURI/
3.) explicit namespace
project xmlns:X=nantNameSpaceURI/
(X can be pretty much anything you want, but should probably be nant)
2 3 are pretty much the same.
1 is the only one I'm not sure of.
I will do a few more tests, but I think this will be the best solution.
BTW. Most people expect 1 2 to work the same. I know I did before I
thought about it, and read about it. :(
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]] On Behalf Of Ian
MacLean
Sent: Wednesday, April 17, 2002 11:09 AM
To: Scott Hernandez
Cc: [EMAIL PROTECTED]
Subject: Re: [nant-dev] nant.xsd sample
Scott Hernandez wrote:
So I did this (sent the email), then realized that if actually use the
existing file (meaning you add an xmlns= to the project element) it
will cause problems with xpath queries.
Before you actually build (use the build file) you need to remove the
default namespace def from the build file. If you leave it, all xpath
queries will fail.
I think I see the problem. In the build file we map the dafault
namespace to the nant namespace but when we come to execute an xpath the
default namspace isn't the nant one so the xpath queries will return
nothing.
Does this mean we will need to specify the namespace in our xpath
queries - using a custom context ? Even if we use prefixes our xpath
queries will still need to be aware of the namespace mapping.
Ian
[snip]
___
Nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
___
Nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
