Re: [xml-dev] XML Redux

[Stephen Green <stephengreenubl@gmail.com>]

I kind of like this idea of a parser 'reverting
to character data' and what is the alternative
if you need to remove ampersands from
some XML (which got in there because no
code was put in place to stop ampersands
or less-thans being included in input in a
web form and the input was subsequently
turned into XML and stored as text - quite
a common scenario of course). It seems
the problem is that XML parsers fall over
with such characters and you might have
to include some sort of peeking and poking
of a stack to retrieve the content. Why do
they fall over? Because their developers
thought that was what was required, it seems.
It might indeed seem like a cludge to have
a fallback but compared to having to mess
around with the stack or such like it might
be just as well to have some guidelines to
tell the parser developers how to handle the
scenario of special characters and other such
complexities and technicalities better than
just rejecting the XML as ill formed and
throwing exceptions. How to handle 'illegals',
etc needs some kind of standardisation
with usability in mind in view of these kinds
of scenario. Treating them as something like
strings, text or character data which can still
be extracted seems like a good starting point.
----
Stephen D Green



On 15 February 2011 20:52, John Cowan <cowan@mercury.ccil.org> wrote:
> Stephen Green scripsit:
>
>> For example the parser might need to have two modes,
>> one lax and one strict, to allow on one hand the parsing of the XML as text
>> ignoring any encoding 'errors' (like XML5, say) so that at least the parser
>> can read in the XML for certain uses (like correction of such 'errors' by
>> character escaping/replacing, etc) and on the other hand something which
>> focuses on parsing 'valid' XML.
>
> I'm not attacking *you* here, Stephen, but I do want to attack the
> widespread meme that HTML5-style formats and parsers are simpler or easier
> to use.  HTML5 is in fact strictly defined: it permits only a single parse
> for any given string of characters, and often its parse is *not* easy to
> understand unless you have grasped the detailed mental model of HTML5.
> Fortunately, there is a smaller and easier-to-understand subset, valid
> HTML5, which allows many fewer possibilities, and it's easy to set up
> even smaller subsets that are as expressive as full HTML5 but have a
> yet simpler model of syntax.
>
> Lax parsers are also more complicated than strict ones.  A strict parser
> sees an error, it just gives up.  But a lax parser has to provide
> an error recovery strategy that makes sense to the user, which is a
> hard problem dating back to the beginning of "automatic programming"
> (i.e. writing code in something other than binary notation).
>
> MicroLark, for example, provides a lax parser of MicroXML, but its
> recovery strategy is intentionally naive (mostly "revert to character
> data") and I would never put it forward as a standard method of error
> recovery.  Doing so feels too much like designing a kludge.  If a kludge
> becomes commonly used, as HTML5 parsing has, it makes sense to try to
> standardize its workings post hoc, but trying to decide in advance what
> errors users will make and what their mental model will expect to find
> strikes me as a hopeless undertaking.
>
> --
> So they play that [tune] on                     John Cowan
> their fascist banjos, eh?                       cowan@ccil.org
>        --Great-Souled Sam                      http://www.ccil.org/~cowan
>