Do people still use XML?
-
I can't use JSON for rendering a parse tree because JSON does not preserve the order of subelements and because of the way multiple values are presented it gives json problems. XML can do it, because XML preserves element order and an element can be present more than once within its parent container. But I don't want to bother if everyone hates XML. What would you do?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I can't use JSON for rendering a parse tree because JSON does not preserve the order of subelements and because of the way multiple values are presented it gives json problems. XML can do it, because XML preserves element order and an element can be present more than once within its parent container. But I don't want to bother if everyone hates XML. What would you do?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
If XML is what you need use XML! See your options and pick the best (optionally the 2 or 3 of them) and use it... Neither JSON nor XML is rocket science... If using XML, just remember to provide a working schema...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
-
I can't use JSON for rendering a parse tree because JSON does not preserve the order of subelements and because of the way multiple values are presented it gives json problems. XML can do it, because XML preserves element order and an element can be present more than once within its parent container. But I don't want to bother if everyone hates XML. What would you do?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I can't use JSON for rendering a parse tree because JSON does not preserve the order of subelements and because of the way multiple values are presented it gives json problems. XML can do it, because XML preserves element order and an element can be present more than once within its parent container. But I don't want to bother if everyone hates XML. What would you do?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
To me the advantage of using XML with Visual Studio is that all functionality is built-in, when using an external library like the Newtonsoft.Json.dll you can get in DLL hell. Especially when using NuGet packages everybody seems to be using their own version of Newtonsoft.Json.dll :mad: Here is an Ebook about XML: https://bookdl.com/978-1484231043/[^]
-
I can't use JSON for rendering a parse tree because JSON does not preserve the order of subelements and because of the way multiple values are presented it gives json problems. XML can do it, because XML preserves element order and an element can be present more than once within its parent container. But I don't want to bother if everyone hates XML. What would you do?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
You are assuming that everyone hates XML. XML/XSLT and the API around it are mature in Java and .NET, and many systems were build based on these technologies.
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
-
You are assuming that everyone hates XML. XML/XSLT and the API around it are mature in Java and .NET, and many systems were build based on these technologies.
Caveat Emptor. "Progress doesn't come from early risers – progress is made by lazy men looking for easier ways to do things." Lazarus Long
I think you misunderstood me. I didn't say everyone hates XML. I only suggested it as a possibility (now that JSON is around)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
When would you ever want a parse tree as a string? Actually when would you want a parse tree at all, instead of building some more convenient (and garbage-free) representation immediately?
The way my parser works you can practically shape the parse tree however you want. Plus you can hard type the values from the lexer - even with your own types. So you basically get an AST straight from the parser. Spitting to JSON just gives you a tree structure you can pass around as JSON
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
If XML is what you need use XML! See your options and pick the best (optionally the 2 or 3 of them) and use it... Neither JSON nor XML is rocket science... If using XML, just remember to provide a working schema...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
There can be no schema for these ones. Or rather, the schema is in EBNF, not XmlSchema/XSD It's by design. This is a parse tree. The elements are going to be different depending on the input grammar. For any input grammar, you should define one XSD to go with it.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
When would you ever want a parse tree as a string? Actually when would you want a parse tree at all, instead of building some more convenient (and garbage-free) representation immediately?
I think I misread you at first so let me try this again. I don't want to parse any strings. I created a tool that allows others to generate parsers to parse strings. As to why you would want to - most of the internet runs on text based protocols. XML and JSON are text based, as are most internet data exchange formats. Also there are things like programming languages. Say you want to parse one, or create your own. This helps with that, or making a query engine, making a SQL DB of your own, or parse SQL scripts whatever. There are plenty of reasons to use a parser.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
There can be no schema for these ones. Or rather, the schema is in EBNF, not XmlSchema/XSD It's by design. This is a parse tree. The elements are going to be different depending on the input grammar. For any input grammar, you should define one XSD to go with it.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Maybe (however as EBNF is finite, and it makes the input finite, which makes outpute finite), but you can create XML schema for every grammar the same way/time you parse it... It should not be that hard...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
-
I think I misread you at first so let me try this again. I don't want to parse any strings. I created a tool that allows others to generate parsers to parse strings. As to why you would want to - most of the internet runs on text based protocols. XML and JSON are text based, as are most internet data exchange formats. Also there are things like programming languages. Say you want to parse one, or create your own. This helps with that, or making a query engine, making a SQL DB of your own, or parse SQL scripts whatever. There are plenty of reasons to use a parser.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I know what a parser is, obviously. But if the output of the parser is a string (such as XML or JSON), then you're building some Rube Goldberg machine that keeps parsing and serializing and parsing again.
That's not the main output. It's just an option to use with the parse tree. The output is actually a pull parser underneath it all, such that
while(parser.Read) {
switch(parser.NodeType)
{
case LLNodeType.NonTerminal:
// ... do stuff
case LLNodeType.Terminal:
// ... do stuff
}
}It builds a parse tree using that, if you want it to, or you can use it directly It works almost exactly like XmlReader
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
Maybe (however as EBNF is finite, and it makes the input finite, which makes outpute finite), but you can create XML schema for every grammar the same way/time you parse it... It should not be that hard...
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
i can, but i have no real reason to although (related) eventually I may make something that compiles XSD documents into fast parser/validators for specific XML documents what i mean is i can potentially do xml validation and xml parsing in one sweep. The XSD could actually speed up the parse compared to parsing raw XML maybe down the road.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
i can, but i have no real reason to although (related) eventually I may make something that compiles XSD documents into fast parser/validators for specific XML documents what i mean is i can potentially do xml validation and xml parsing in one sweep. The XSD could actually speed up the parse compared to parsing raw XML maybe down the road.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
It maybe of interest for you https://www.genivia.com/articles/icws2008ppg.pdf[^]
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
-
It maybe of interest for you https://www.genivia.com/articles/icws2008ppg.pdf[^]
"The greatest enemy of knowledge is not ignorance, it is the illusion of knowledge". Stephen Hawking, 1942- 2018
looks like someone already had my idea. :-D
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I can't use JSON for rendering a parse tree because JSON does not preserve the order of subelements and because of the way multiple values are presented it gives json problems. XML can do it, because XML preserves element order and an element can be present more than once within its parent container. But I don't want to bother if everyone hates XML. What would you do?
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
codewitch honey crisis wrote:
But I don't want to bother if everyone hates XML.
Aw, ffs, most people will not even know that it is being used. We're not religious, so we can't burn XML just because a few people don't know what it is for. If you create entire databases in XML, you'll hate it, yes. If you use it as a communication-protocol, you'll hate it too. Use it as an exchange-format, and it will work perfectly. I would store a tree in an in-memory SQLite3 database. Quick, efficient, and easy to write to a SQLite-db on disk and have the user send you their tree by mail, if you need it for debugging.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
codewitch honey crisis wrote:
But I don't want to bother if everyone hates XML.
Aw, ffs, most people will not even know that it is being used. We're not religious, so we can't burn XML just because a few people don't know what it is for. If you create entire databases in XML, you'll hate it, yes. If you use it as a communication-protocol, you'll hate it too. Use it as an exchange-format, and it will work perfectly. I would store a tree in an in-memory SQLite3 database. Quick, efficient, and easy to write to a SQLite-db on disk and have the user send you their tree by mail, if you need it for debugging.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
I'm not even using the XML. It's just a feature i'm thinking of adding for end user devs that use my stuff.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I'm not even using the XML. It's just a feature i'm thinking of adding for end user devs that use my stuff.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Consider yourself to be SQL Server; do you allow export in XML, or would you prefer not to because a few people "hate it"? Programming isn't politics, technologies don't have to be popular.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
Consider yourself to be SQL Server; do you allow export in XML, or would you prefer not to because a few people "hate it"? Programming isn't politics, technologies don't have to be popular.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
I do crap that's not popular all the freakin time. :)
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013 -
I do crap that's not popular all the freakin time. :)
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013#realJSOP wrote:
I do crap that's not popular all the freakin time. :)
Like asking who took your template-permissions? :laugh:
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
