Hi Im not sure what you mean by not xml parsers are low but I wouldnt assume son, string based parsers are quite common for small helper/utilities. Indeed they dont care as plain xml parsers dont care of all changes related to the model (= either there is a breaking change and you must handle it or there is none and you can ignore it).
For model version v4.0.0/v4.1.0, ignoring the namespace but capturing it to bé able to have the info is the easiest to handle it - at least with jaxb. I know xslt is referenced a lot but that is just a way to map models, there a superset of both models is way easier to maintain than a mapping with a third pivot format (for now). So maven doesn't go against xml strictly speaking, it just integrates it = not sure which issue we do try to solve in this thread. Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Javaccino founder (Java/.NET service - contact via linkedin) Le sam. 4 avr. 2026, 14:24, Chris Lafren <[email protected]> a écrit : > Hi, > as suggested by Herve Boutemy [1], I'm creating a new discussion on the > namespace topic because I couldn't find the previous one(s). > > I understand the percentage of Maven users who parse/generate pom files > with non-Maven XML tooling is probably very low. > But you need to realize that Maven pom files are a tiny speck in the XML > ecosystem. > > If some people don't know the differences between an XML namespace and an > XML schema, they should read the relevant W3C specifications instead of > reinventing the wheel and changing the way XML is supposed to work. > > Here are a few pointers. > 1. An XML namespace is identified by its URI: > https://www.w3.org/TR/xml-names/#concepts > By changing the URI, you create an entirely new namespace. > > 2. The root element of an XML schema has a targetNamespace attribute: > https://www.w3.org/TR/xmlschema-1/#declare-schema > Multiple schemas can use the same targetNamespace value. > > 3. The schemaLocation attribute from the XMLSchema-instance namespace > provides a way to associate a namespace URI with a schema: > https://www.w3.org/TR/xmlschema-1/#xsi_schemaLocation > Can't you infer the modelVersion from that? > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > https://maven.apache.org/xsd/maven-4.0.0.xsd" > vs > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > https://maven.apache.org/xsd/maven-4.1.0.xsd" > > Let's use XSLT as an example. > XSLT 1.0 was published on 1999/11/16 and defined its namespace URI as: > http://www.w3.org/1999/XSL/Transform > https://www.w3.org/TR/xslt-10/#xslt-namespace > XSLT 2.0 was first published on 2007/01/23 and uses the same namespace URI: > https://www.w3.org/TR/xslt20/#xslt-namespace > NB: the updated 2021/03/30 version didn't modify it. > XSLT 3.0 was published on 2017/06/08 and uses the same namespace URI: > https://www.w3.org/TR/xslt-30/#xslt-namespace > XSLT 4.0 also uses the same namespace URI in its 2026/03/31 working draft: > https://qt4cg.org/specifications/xslt-40/Overview.html#xslt-namespace > > The XSLT model has changed significantly over the years yet the namespace > URI has remained constant. > Did you ever wonder why? > > Aside from the modelVersion inference that was mentioned at the start of > the vote thread [2], are there more reasons that "justify" the namespace > change? > > I asked some AI tool to compare maven-4.0.0.xsd with maven-4.1.0-rc-4.xsd. > The changes seem rather limited but AI tools are notoriously unreliable, > so... > > Regards, > Chris > > [1] https://lists.apache.org/thread/trxmjc63fp2of83zyvzhp9jt59vh56c1 > [2] https://lists.apache.org/thread/p59nlz2onjkszskxblo5vrcb7chjmnwl > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
