[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>
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>
value </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,
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>
value </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
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>
value </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