upvote

points

by petcat7 hours ago |
comments
upvoteby diffuse_l7 hours ago|
next
[-]
That's if you parse the into a DOM and work on that. If you use SAX parsing, it makes it much better regarding the memory footprint.

But of course, working with SAX parsing is yet another, very different, bag of snakes.

I still hope that json parsing had the same support for stream processing as XML (I know that there are existing solutions for that, but it's much less common than in the XML world)

reply
upvoteby alexpetros6 hours ago|
prev|
next
[-]
In the context of the article, "cheap" means "easy to set up" not "computationally efficient." The article is making the argument that there are situations in which you benefit from sacrificing the latter in favor of the former. You're right that it's annoyingly slow to parse though and that does cause issues I'd like to fix.
reply
upvoteby hrmtst938373 hours ago|
prev|
next
[-]
If you want a parser that actually checks the XML spec and various edge cases, then parsing goes from human-readable config to O(n^2) string handling. The funny part is how often people silently accept partial or broken XML in prod because revisiting schema validation years later is a nightmare. If you want cheap parsing, you end up writing a regex or DOM walker and hoping for the best, which raises the question of why not just use JSON or invent a different DSL to start.
reply
upvoteby sparkie1 hours ago|
parent|
[-]
(Properly formatted) XML can be parsed, and streamed, by a visibly-pushdown automaton[1][2].

"Visibly Pushdown Expressions"[3] can simplify parsing with a terse syntax styled after regular expressions, and there's an extension to SQL which can query XML documents using VPAs[4].

JSON can also be parsed and validated with visibly pushdown automata. There's an interesting project[5] which aims to automatically produce a VPA from a JSON-schema to validate documents.

In theory these should be able outperform parsers based on deterministic pushdown automata (ie, (LA)LR parsers), but they're less widely used and understood, as they're much newer than the conventional parsing techniques and absent from the popular literature (Dragon Book, EAC etc).

[1]:https://madhu.cs.illinois.edu/www07.pdf

[2]:https://www.cis.upenn.edu/~alur/Cav14.pdf

[4]:https://web.cs.ucla.edu/~zaniolo/papers/002_R13.pdf

[3]:https://homes.cs.aau.dk/~srba/courses/MCS-07/vpe.pdf

[5]:https://www.gaetanstaquet.com/ValidatingJSONDocumentsWithLea...

reply
upvoteby g947o22 minutes ago|
parent|
[-]
Without looking, I guessed that all your quotes come from academic papers. I was right.

Because real life is nothing like what is taught in CS classes.

reply
upvoteby sparkie14 minutes ago|
parent|
[-]
I'm not an academic and have extensive experience with parsing.

But for whataver reason, VPAs have slipped under my radar until very recently - I only discovered them a few weeks ago and have been quite fascinated. Have been reading a lot (the citations I've given are some of my recent reading), and am currently working on a visibly pushdown parser generator. I'm more interested in the practical use than the acamedic side, but there's little resources besides academic papers for me to go off.

Thought it might be interesting to share in case others like me have missed out on VPAs.

reply
upvoteby bubbleRefuge7 hours ago|
prev|
[-]
Yup. SAP and their glorious idocs with german acronyms
reply