11–20 of 37 posts
Cool. This plus xml2js should make the whole process of extracting data from a bunch of 3rd-party xml files I'm currently dealing with a lot easier.
I wish developers would stop copying SQL. It's like making fancy new languages, and then adding libraries that help you emulate COBOL. SQL is not the first, the last, or the best query language ever created, it's just the best marketed. It's not even properly relational, it's based on a series of shell scripts on multics for crying out loud!
This looks interesting, I wonder whether the path syntax would work in URLs.
I wish developers would stop copying SQL. It's like making fancy new languages, and then adding libraries that help you emulate COBOL. SQL is not the first, the last, or the best query language ever created, it's just the best marketed. It's not even properly relational, it's based on a series of shell scripts on multics for crying out loud!
I wish developers would stop copying SQL. It's like making fancy new languages, and then adding libraries that help you emulate COBOL. SQL is not the first, the last, or the best query language ever created, it's just the best marketed. It's not even properly relational, it's based on a series of shell scripts on multics for crying out loud!
This really doesn't look much like SQL to me - much more like an interesting variation on XPath...
Why do you think it is a copy of SQL?
This looks interesting, I wonder whether the path syntax would work in URLs.
Can you unpack that question a little for me? As in, could you use a spahql selection as the path component of some request? I don't see why not, but the escaping will probably look a little ugly.
www.example.com/data.json,
www.example.com/data.json/user
www.example.com/data.json/categories/*
www.example.com/data.json/categories/0/products
www.example.com/data.json//avatarLooks far too similarly pronounced to SPARQL ( http://www.w3.org/TR/rdf-sparql-query/ ). Or is that deliberate?
I hope I don't cause too much confusion!