[yast-devel] Yast XML parser and strictness
Hi, as you can read in previous mails, I am playing with xml parser used in YaST. Nokogiri looks like the best option due to its relax ng support and its availability in SLE (used in SLES-HA). And nokogiri has also one interesting feature and that is relaxed parsing that tries hard to parse document even when it is malformed[1] ( but you can still log errors). Example that nokogiri can parse: <test> <not_closed> <not_closed2> value </not_opened> </test> which results in something like test -> not_closed -> not_closed2 -> value tree I check old yast yast parser and it is strict here and return nil and set error. Question is should we keep old behavior or try to relax it and just logs errors and warnings? For working profiles nothing changes. Josef [1] https://nokogiri.org/tutorials/ensuring_well_formed_markup.html -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Mon, Apr 06, 2020 at 05:15:46PM +0200, josef Reidinger wrote:
as you can read in previous mails, I am playing with xml parser used in YaST. Nokogiri looks like the best option due to its relax ng support and its availability in SLE (used in SLES-HA).
And nokogiri has also one interesting feature and that is relaxed parsing that tries hard to parse document even when it is malformed[1] ( but you can still log errors). Example that nokogiri can parse: <test> <not_closed> <not_closed2> value </not_opened> </test>
which results in something like test -> not_closed -> not_closed2 -> value tree
I check old yast yast parser and it is strict here and return nil and set error. Question is should we keep old behavior or try to relax it and just logs errors and warnings? For working profiles nothing changes.
I think there parser should continue to be strict. Just imagine people start to use broken XML as AutoYaST profiles. Years later we cannot change the XML parser implementation because it behaves different for those broken profiles and people complain that we break compatibility. Also see the criticism section in https://en.wikipedia.org/wiki/Robustness_principle. ciao Arvin -- Arvin Schnell, <aschnell@suse.com> Senior Software Engineer, Research & Development SUSE Software Solutions Germany GmbH Maxfeldstraße 5 90409 Nürnberg Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On 2020-04-06 21:38, Arvin Schnell wrote:
On Mon, Apr 06, 2020 at 05:15:46PM +0200, josef Reidinger wrote:
as you can read in previous mails, I am playing with xml parser used in YaST. Nokogiri looks like the best option due to its relax ng support and its availability in SLE (used in SLES-HA).
And nokogiri has also one interesting feature and that is relaxed parsing that tries hard to parse document even when it is malformed[1] ( but you can still log errors). Example that nokogiri can parse: <test> <not_closed> <not_closed2> value </not_opened> </test>
which results in something like test -> not_closed -> not_closed2 -> value tree
I check old yast yast parser and it is strict here and return nil and set error. Question is should we keep old behavior or try to relax it and just logs errors and warnings? For working profiles nothing changes.
I think there parser should continue to be strict. Just imagine people start to use broken XML as AutoYaST profiles. Years later we cannot change the XML parser implementation because it behaves different for those broken profiles and people complain that we break compatibility.
I agree. Let's be strict and fail early. Let's not perpetuate the mistakes.
Also see the criticism section in https://en.wikipedia.org/wiki/Robustness_principle.
That's kind of similar to the idea of making errors during installation visible right away, instead of trying to hide them and just continue the process pretending nothing happened. Cheers. -- Ancor González Sosa YaST Team at SUSE Linux GmbH -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
On Tue, 7 Apr 2020 10:43:52 +0200 Ancor Gonzalez Sosa <ancor@suse.de> wrote:
On 2020-04-06 21:38, Arvin Schnell wrote:
On Mon, Apr 06, 2020 at 05:15:46PM +0200, josef Reidinger wrote:
as you can read in previous mails, I am playing with xml parser used in YaST. Nokogiri looks like the best option due to its relax ng support and its availability in SLE (used in SLES-HA).
And nokogiri has also one interesting feature and that is relaxed parsing that tries hard to parse document even when it is malformed[1] ( but you can still log errors). Example that nokogiri can parse: <test> <not_closed> <not_closed2> value </not_opened> </test>
which results in something like test -> not_closed -> not_closed2 -> value tree
I check old yast yast parser and it is strict here and return nil and set error. Question is should we keep old behavior or try to relax it and just logs errors and warnings? For working profiles nothing changes.
I think there parser should continue to be strict. Just imagine people start to use broken XML as AutoYaST profiles. Years later we cannot change the XML parser implementation because it behaves different for those broken profiles and people complain that we break compatibility.
I agree. Let's be strict and fail early. Let's not perpetuate the mistakes.
Also see the criticism section in https://en.wikipedia.org/wiki/Robustness_principle.
That's kind of similar to the idea of making errors during installation visible right away, instead of trying to hide them and just continue the process pretending nothing happened.
Cheers.
Thanks for both opinion. So I will use strict behavior. Josef -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org
participants (3)
-
Ancor Gonzalez Sosa -
Arvin Schnell -
josef Reidinger