> And if you ask for my own idea, I would tend to preserve the comments, until there be better solution but sadly I just think in the shitty xml/xsd world, there might never be a better solution......
Xeno Amess <xenoam...@gmail.com> 于2025年2月10日周一 21:45写道： > > Side note: technically this doesn't help to move content to tags since we > have the info of comment location and content already, what we miss is > "should we keep it or not" and this is the same for custom xsds - being > worse for XSD when they are nested in kept elements so the other topic > about custom tags can end up being way more complex IMHO. > > YES! you get what I mean and what I worried about exactly. > And if you ask for my own idea, I would tend to preserve the comments, > until there be better solution > > > Romain Manni-Bucau <rmannibu...@gmail.com> 于2025年2月10日周一 21:32写道： > >> Are we saying comments should be written in tags? I think we are starting >> to speak about another topic - which is relevant and mainly "how can we >> handle external XSD securely" - but comment topic stays, as mentionned >> there are real life use cases for comments where you do not want to go >> with >> a custom xsd nor even a tag since you want to write a comment IMHO. >> >> Side note: technically this doesn't help to move content to tags since we >> have the info of comment location and content already, what we miss is >> "should we keep it or not" and this is the same for custom xsds - being >> worse for XSD when they are nested in kept elements so the other topic >> about custom tags can end up being way more complex IMHO. >> >> 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 >> > >> >> >> Le lun. 10 févr. 2025 à 14:15, Xeno Amess <xenoam...@gmail.com> a écrit : >> >> > well, adding custom elements, makes it cannot pass xsd, right? >> > or we shall allow any element name? but that would kill typo check, >> like if >> > somebody wrongly said, <dependencys>, and spend a whole day finding >> what be >> > wrong. >> > or is there some way to allow some...prefix?or allow-all-namespace like >> > <custom:property1> or something? >> > >> > Gary Gregory <garydgreg...@gmail.com> 于2025年2月10日周一 20:57写道： >> > >> > > I agree FWIW, this is a problem XML standards solved decades ago. >> > Comments >> > > should be considered invisible, in fact many parsers don't surface >> them. >> > > Between processing instructions and namespaces, a tool should have >> all it >> > > needs IMO. >> > > >> > > Gary >> > > >> > > On Mon, Feb 10, 2025, 07:45 Elliotte Rusty Harold <elh...@ibiblio.org >> > >> > > wrote: >> > > >> > > > On Mon, Feb 10, 2025 at 10:02 AM Xeno Amess <xenoam...@gmail.com> >> > wrote: >> > > > > >> > > > > > Sometimes comments are used to embed additional machine-readable >> > > > metadata. >> > > > > yes and considering somebody would like to use this for a maven >> > > extension >> > > > > or something... >> > > > >> > > > Yes, that's a pretty common antipattern. Embedding other markup >> > > > formats inside XML is baroque, confusing, and tool hostile. The >> better >> > > > approach is to add additional XML markup to the document. In this >> > > > specific instance that means Maven would stop erroring if it sees >> > > > elements it doesn't recognize. That is, it asks the question "Do I >> > > > have everything I need to build this project?" instead of "Do I >> > > > understand every element in this pom?" >> > > > >> > > > A slightly less radical approach would be to ignore elements not in >> > > > Maven's own namespace. >> > > > >> > > > -- >> > > > Elliotte Rusty Harold >> > > > elh...@ibiblio.org >> > > > >> > > > >> --------------------------------------------------------------------- >> > > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> > > > For additional commands, e-mail: dev-h...@maven.apache.org >> > > > >> > > > >> > > >> > >> >
