Regarding the namespace discussion, I'd like to better understand the
concrete difficulty with processing POMs that have different namespaces.
In XSLT, a simple namespace normalization pre-processing step handles this:
<xsl:template match="*">
<xsl:element name="{local-name()}"
namespace="http://maven.apache.org/POM/4.0.0";>
<xsl:apply-templates select="@*|node()"/>
</xsl:element>
</xsl:template>
In XPath, you can use local-name():
//*[local-name()='dependency']
Or in XPath/XSLT 2.0+, wildcard namespace matching:
//*:dependency
I want to make sure we're weighing the actual cost accurately on both sides
before making a decision.
Guillaume
Le sam. 14 mars 2026 à 22:15, Elliotte Rusty Harold <[email protected]> a
écrit :
> On Sat, Mar 14, 2026 at 4:17 PM Hervé Boutemy <[email protected]>
> wrote:
> >
> > sorry, I don't get what has been done, "years ago": can you explain?
> >
> > and TBH, I don't get what changing namespace value really breaks beyond
> some
> > very theoretical aspect: so changing or not changing in one or the other
> > direction, what does it break?
>
> I have said this before. I'm guess I'm going to have to say it again.
> The problems are not theoretical. I have personally spent extra months
> of development on projects (which Google paid for at the time, so
> probably six figures worth of Google's money) because I could not use
> standard XML tooling like XSLT and XPath to process pom.xml files. The
> specific reason was Maven not using namespaces as designed and
> documented in the Namespaces in XML specification. Adding new
> namespaces makes the problem worse.
>
> There are other tools I have never bothered to build because they'd
> simply be too challenging and expensive to create.
>
> There is no benefit to introducing new namespaces with every version
> of Maven and substantial cost. The burden of proof is on those who
> claim we should change the namespace and work against the design of
> XML namespaces.
>
> --
> Elliotte Rusty Harold
> [email protected]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
--
------------------------
Guillaume Nodet
