Re: [xsl] XSLT 3.0 processor accepting non well-formed XML inputs

["Graydon graydon@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>]

On Sat, Mar 02, 2019 at 04:21:13AM -0000, Dimitre Novatchev dnovatchev@xxxxxxxxx scripsit:
> Taking all this into account, will it be useful to relax some
> requirements toward the streamed XML, so that people will not have to
> spend time over such seeming "issues", because in the relaxed terms
> these will simply become non-existent?

There's always the risk of confusing "useful" and "practical". ("this
would be great if we could do it")

XML's largest downside is the parse requirement; you have to do quite a
bit of work to turn the text representation into the nodes.  This has a
lot to do with why "lighter" hierarchical models (like JSON) caught on
for data exchange.

It's pretty easy to argue that XML is only required (or justified) when
the data exchange is complicated.

Accepting that such things exist (central prescription checking by
regional health authorities comes to mind), the question I think turns
into "what are we getting for the parse?"

With relaxed constraints, all the useful stuff -- the certainty that
there are things that XML won't let you do -- goes away.  (Rather like
how the "put the Microsoft `high ASCII' characters in the XML character
set" decision made well-formedness less useful.)

I have absolutely no issues with the idea of "this operation can happen
without a complete parse", but would really not like "complete parse"
and "partial parse" operations becoming mutually ambiguous.

(Does "doc-available()" imply a complete parse?)

-- Graydon