Re: [lmi] Why should we sort XML documents?

[Greg Chicares]

On 2018-03-04 22:35, Vadim Zeitlin wrote:
[...]
> On Sun, 4 Mar 2018 01:15:34 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2018-03-04 00:38, Vadim Zeitlin wrote:
> GC> > On Fri, 2 Mar 2018 17:42:58 +0000 Greg Chicares <address@hidden> wrote:
> GC> > GC> Sorting is necessary only if XSD validation requires it.
> [...]
> GC> >  I think it does, but this would be easy to fix if it's not desired: we
> GC> > need to use "interleave", which is represented by "&" in Relax NG 
> compact
> GC> > syntax that we use.
> GC> [...]
> GC> > I don't include the patch for this change because I didn't have the 
> time to
> GC> > test it yet, but I'm relatively sure it ought to work.
> GC>
> GC> I don't think that change will be wanted:
> GC> 
> GC> - IIRC, "interleave" doesn't let us diagnose missing elements well.
> 
>  No, sorry, this doesn't seem to be correct. Replacing commas with
> ampersands in multiple_cell_document.rnc or, alternatively, replacing
> xs:sequence with xs:all in multiple_cell_document.xsd, still results in the
> expected error when validating sample.cns after removing case_default tag
> from it:
> 
> - With jing and RNC I get
> 
> sample.cns:399:26: error: element "multiple_cell_document" incomplete; 
> missing required element "case_default"
> 
>   which is just as good as the current error
> 
> sample.cns:3:19: error: element "class_defaults" not allowed yet; missing 
> required element "case_default"

But that's unaffected by 'sort_cell_subelements.xsl', which documents
its purpose as:

|    Sort subelements of a <cell> element.

Thus, given:

<?xml version="1.0"?>
<multiple_cell_document version="2" data_source="1">
  <class_defaults>
    <cell version="8">
      <Address/>
      <AccidentalDeathBenefit>No</AccidentalDeathBenefit>
  ...
  <case_default>

it would move the <Address> element down one line, but it wouldn't
move <case_default> before <class_defaults>, AIUI.

The most relevant discussion I find in our archives is:
  https://lists.nongnu.org/archive/html/lmi/2012-10/msg00000.html
I'm not sure that analysis is complete and comprehensive, or that
we chose the best possible design option. But I am sure that we
spent a lot of time on it, and chose carefully.

Now there's a procedural question before us: should we revisit
that design decision now?

There are always theoretical reasons to revisit any decision.
There's no practical reason, though: this has worked just fine
in production for years, and the only issue that has ever been
noted seems to have been a 'wine' defect not reproducible with
an upgraded 'wine'. Furthermore, no end user uses 'wine', and
on native msw applying 'sort_cell_subelements.xsl' doesn't seem
to take any appreciable time. We really have nothing to gain.

But there are strong reasons not to mess with something that
works. Changing a decision that was made carefully calls for
great care--we'd have to spend a good deal of time on it. The
cost-benefit analysis does not favor that, because the effort
is considerable and there is no significant practical benefit.
E.g., the 2012 design is backed up by 'test_schemata.sh' tests:
it would take time and effort to revamp them, too, because we
certainly aren't going to replace careful work with something
less rigorous. And of course any change risks introducing new
errors. We have nothing to gain, but much to lose--and more
compelling ways to spend our limited time.

The opposite of "Linus's Law" applies to lmi. Given so few
eyeballs, all bugs are deep. Linus can "release early, release
often", because he has thousands of expert users who expect
new features to be buggy, and are willing to find and fix the
bugs. But lmi has only dozens of users, who don't have the
expertise to diagnose our mistakes or fix them--if anything
breaks, we have failed them. And any failure is grave, because
it means they can't get their work done. There's no tolerance
for mistakes, and that's why lmi is a Cathedral, not a Bazaar.