On Mon, Mar 16, 2026 at 7:22 AM Guillaume Nodet <[email protected]> wrote: > > 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>
Assuming prefixes aren't in play, which I admit they usually aren't because Maven gets that wrong too. This also fails if there are non-Maven namespaces in the document like XInclude's. You can probably make a more complicated template that fixes that too, but it's still doubling the number of transforms you have to run, or adding transforms to every document read just to make a simple XPath query, all to allow extra namespace URIs that serve no purpose. Regardless it's still easier if we don't have to do preprocessing. > In XPath, you can use local-name(): > //*[local-name()='dependency'] Yes, you can but it gets really ugly really fast. > Or in XPath/XSLT 2.0+, wildcard namespace matching: > //*:dependency XPath 1.0 and XSLT 1.0 are far more broadly supported and available. Last I checked there was essentially a single source for XPath 2.0+ in Java. Michael Key's saxon. I'm not sure what the landscape looks like in other environments. But I take your points. There are workarounds. These might be worth considering if there were an actual benefit to changing the namespace. The kicker is there's no such benefit. Absolutely nothing is gained by proliferating namespaces. It is excess complexity that slows development and makes code more complex for no benefit. No one has presented a technical reason why we should change the namespace. It is simpler and easier to just not do that. -- Elliotte Rusty Harold [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
