[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML Redux
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] |
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|