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

[Vadim Zeitlin]

On Mon, 5 Mar 2018 13:49:24 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2018-03-04 22:35, Vadim Zeitlin wrote:
GC> [...]
GC> > On Sun, 4 Mar 2018 01:15:34 +0000 Greg Chicares <address@hidden> wrote:
GC> > 
GC> > GC> On 2018-03-04 00:38, Vadim Zeitlin wrote:
GC> > GC> > On Fri, 2 Mar 2018 17:42:58 +0000 Greg Chicares <address@hidden> 
wrote:
GC> > GC> > GC> Sorting is necessary only if XSD validation requires it.
GC> > [...]
GC> > GC> >  I think it does, but this would be easy to fix if it's not 
desired: we
GC> > GC> > need to use "interleave", which is represented by "&" in Relax NG 
compact
GC> > GC> > syntax that we use.
GC> > GC> [...]
GC> > GC> > I don't include the patch for this change because I didn't have the 
time to
GC> > GC> > test it yet, but I'm relatively sure it ought to work.
GC> > GC>
GC> > GC> I don't think that change will be wanted:
GC> > GC> 
GC> > GC> - IIRC, "interleave" doesn't let us diagnose missing elements well.
GC> > 
GC> >  No, sorry, this doesn't seem to be correct.
[...]
GC> But that's unaffected by 'sort_cell_subelements.xsl', which documents
GC> its purpose as:
GC> 
GC> |    Sort subelements of a <cell> element.

 Sorry, I indeed failed to notice this, but it doesn't actually matter, my
point that "interleave" does diagnose missing elements well still remains.

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

 Thanks for the link, I have, of course, completely forgotten about this
message and I'm not completely sure if I really thought about this back
when it was posted. Because if I did I would probably objected to this
part:

    > but replacing <xs:sequence> with <xs:all> would mean we could
    > never add a subelement that occurs more than once (as might be
    > desirable, e.g., for the insureds on a multiple-life policy, or
    > for multiple fund selections). We don't want to paint ourselves
    > into that corner, and the other workarounds are too complicated.

because it seems wrong to preemptively use a complicated solution instead
of using simple one now, knowing that we can always switch to a more
complex one later if really needed, i.e. if any such elements are really
added. Of course, maybe it only seems so when rereading this today, after
5+ years during which no such elements materialized, but I do think this
would have been a reasonable question even back then.

GC> on native msw applying 'sort_cell_subelements.xsl' doesn't seem
GC> to take any appreciable time. We really have nothing to gain.

 I somewhat disagree with this too. Simplification is always nice, and
removing the need to sort the cells here would allow us to not use
libxsltwrapp (and hence libxslt) at all any longer once the XSL-FO code is
finally removed which is, IMHO, a not-negligible payoff for very little
work.

GC> But there are strong reasons not to mess with something that
GC> works. Changing a decision that was made carefully calls for
GC> great care--we'd have to spend a good deal of time on it. The
GC> cost-benefit analysis does not favor that, because the effort
GC> is considerable and there is no significant practical benefit.
GC> E.g., the 2012 design is backed up by 'test_schemata.sh' tests:
GC> it would take time and effort to revamp them, too, because we
GC> certainly aren't going to replace careful work with something
GC> less rigorous.

 Sorry, but I really don't think anything at all needs to be changed in
test_schemata.sh. I still don't see what does it, and the underlying issues
of RNC to XSD conversion, have to do with the topic at hand. With the
current schema, we can use "interleave" in RNC and "xs:all" in XSD just
fine and nothing else needs to be changed.

GC> And of course any change risks introducing new
GC> errors. We have nothing to gain, but much to lose--and more
GC> compelling ways to spend our limited time.

 I'm not going to argue with it, but I think you vastly overestimate the
impact of this change. It consists in only removing the code, not replacing
it, and we seem to agree that this code is not useful right now. So it just
seems strange to prefer to keep it, and even keep linking with an entire
extra library just to be able to do it, instead of simply dropping it.

 Regards,
VZ