91–100 of 131 posts
The reinvention of XML in JSON is almost complete - JMESPath vs XPath, JSON Schema vs XML Schema etc. If you need semi structured data to that level, consider using XML instead - you can validate it, there's plenty of tools, it's very stable and mature etc
The reinvention of XML in JSON is almost complete - JMESPath vs XPath, JSON Schema vs XML Schema etc. If you need semi structured data to that level, consider using XML instead - you can validate it, there's plenty of tools, it's very stable and mature etc
JSON still doesn’t support comments though, they need to work on that.
Why do you need comments in a structure of nested - unique key mappings - arrays - strings - numbers - booleans - nulls ? You can include comments, just like any string, into it, just reserve a key with unique name, if you want. From JSON parser/transformer point of view, "comment" as a concept isn't a data structure piece, it's rather "intent" piece.
https://www.couchbase.com/products/n1ql
It's not standalone though, you need Couchbase to use it.
The reinvention of XML in JSON is almost complete - JMESPath vs XPath, JSON Schema vs XML Schema etc. If you need semi structured data to that level, consider using XML instead - you can validate it, there's plenty of tools, it's very stable and mature etc
The "reinvention" is not complete and will never be necessary. The difference is that XPath is necessary to query XML because it's a botched horribly overcomplicated, designed-by-committee markup language. Except for tools like jq no such language is actually required for JSON because it maps on to language structures that always exist. Neither JSON schema or XML schema are particularly popular - and for good reason.…
There is a lot of use for libraries dealing with time and dates. When you want to cover all cases, at some point you get to the situation when you have to allow variable number of seconds in a minute - not always 60, but sometimes 59 or 61, or may be even different numbers. And you don't know in advance - for arbitrary long future - which minutes will have which number of seconds.
So, for your timekeeping system to maintain precision, you have to allow external updates for when a minute will be considered non-60 seconds.
And those cases could happen more often than changing a list of valid country codes.
What would you do with time then?
The reinvention of XML in JSON is almost complete - JMESPath vs XPath, JSON Schema vs XML Schema etc. If you need semi structured data to that level, consider using XML instead - you can validate it, there's plenty of tools, it's very stable and mature etc
Last time I checked, XML was uncertain which validation should I use. DTD, Schema, other solutions. Each has syntax/structure and 1st page explanation so cryptic, that I don’t even understand where do I begin. I don’t like js/json at all, but for json (and without much js knowledge) I can roll out simple validation in less time than is needed to understand these schema formats. If my structure is dynamic, omg it will…
DTD was considered obsolete more than a decade ago.
Nobody uses anything but XSD nowadays.
My tiny lib with very similar functionality: [1]. The query syntax is slightly different though. Also I decided to re-use JS for evaluation of sub-expressions instead of implementing own full-fledged parser. [1] https://github.com/xonixx/jsqry
I love libraries like this, which is small enough to be read in one sitting. I can scan through and get a general understanding of everything that it does. The "evaluation of sub-expressions" made me curious. This line: token.func = Function('_,i,args', 'return ' + token.val); ..could be a potential security issue with user-submitted expressions?
var name = one(users, '[_.id==?].name', 123)
JMESPath limitations:
- No simple if/else, but it is possible using a hack, documented below.
- The to_number function doesn't support boolean values, but it is possible using a hack, documented below.
- can't reference parents when doing iteration. Why? All options for iteration, [* ] and map, all use the iterated item as the context for any expression. There's no opportunity to get any other values in. May be possible for a fixed set of lengths. Something akin to the following (except there is no syntax for switching or if statements):
switch (length):
case 1: [expression[0]]
case 2: [expression[1], expression[1]]
case 3: [expression[0], expression[1], expression[2]]
...
- No basic math operations, add, multiply, divide, mod, etc. Why? Nobody added those operators/functions.
- There's a join, but no split.
- No array indexing based on expression. Why? Indexing is done based on a number or a slice expression, which also doesn't support expressions. Here's the ABNF:
bracket-specifier = "[" (number / "* " / slice-expression) "]" / "[]"
- No ability to get the index of an element in a list
Hacks:
Convert true/false to number:
boolean_expression && `1` || `0`
Option 1)
[{q:CONDITIONAL_EXPRESSION, v:IF_RESULT_EXPRESSION},{q:!COND_EXPRESSION,v:ELSE_RESULT_EXPRESSION}][?q]|[0].v
{"if":CONDITIONAL_EXPRESSION, "ctx":@} | [{q:if ,v:ctx.IF_EXPRESSION},{q:!if,v:ctx.ELSE_EXPRESSION}][?q]|[0].vEarlier quoted context omitted.
The "reinvention" is not complete and will never be necessary. The difference is that XPath is necessary to query XML because it's a botched horribly overcomplicated, designed-by-committee markup language. Except for tools like jq no such language is actually required for JSON because it maps on to language structures that always exist. Neither JSON schema or XML schema are particularly popular - and for good reason.…
> * Keep that schema file updated by hand every time something like Sudan breaking in two happens (no). There is a lot of use for libraries dealing with time and dates. When you want to cover all cases, at some point you get to the situation when you have to allow variable number of seconds in a minute - not always 60, but sometimes 59 or 61, or may be even different numbers. And you don't know in advance - for arbit…
Earlier quoted context omitted.
What reasons did you not go with SQL itself? I may not fully understand what you're trying to do, but in any case it sounds really interesting.
I never tried it but I am expecting the performance to be not good enough, it takes already several minutes with code specifically written to perform the calculations I am interested in. And because I don't know what exactly I am looking for I need more or less interactive speed so that I can try out many different ways to look at the data. But maybe I could use [materialized] views to convey enough information to th…
Besides's this projects cli, jp ( https://github.com/jmespath/jp ), I see jl ( https://github.com/chrisdone/jl ) and jq ( https://github.com/stedolan/jq/ ) in the comments. I wonder if anyone has had experience with all three (or even just one) and can comment on their experiences?
jmespath is more limited, but is well specified and easier to fit in your head. It's also much more appropriate for using as a library from other projects, since it has clean implementations in many languages. It's also an advantage in this case that it can't do everything, since you can more realistically provide untrusted user input.
jmespath's default (Go) CLI isn't as fully featured as jq, unfortunately.