Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON Schema Store

schemastore.org

Post reply on HN
Print view View original

121–130 of 150 posts

Re: JSON Schema Store

#121

Post by fauigerzigerk »

crabbone wrote: post #115
fauigerzigerk wrote: post #85

Earlier quoted context omitted.

>I.e. learning about namespaces would take a programmer couple of hours, including a foosball match and a coffee break It's not about the time it takes to learn about namespaces. I'm talking about the complexity that namespaces and entities add to the data model and the requirement to actually handle them throughout the entire stack. You can normalise and compare arbitrary pieces of JSON using only information availa…

> I'm talking about the complexity that namespaces and entities add to the data model I've worked a lot with XML, and I have no idea what complexity are you talking about. This just wasn't complex / difficult. Once you've learned what this was about, this was your second nature. Eg. I spent a lot of time working with MXML -- that is an XML format for Adobe Flex markup similar to XAML and a bunch of others of the same…

I worked with XML extensively for many years starting back in the 1990s. When I'm saying that namespaces add complexity to the data model I'm not complaining about them being difficult to use or understand.

>Dream on. No, you cannot. It depends on parser implementation. For example, you have two 20-digit numbers where 15 most significant digits are the same. Are these numbers the same number or a different number in JSON?

That's just a mildly interesting interoperability edge case that can be worked around. I agree that it's not good, but it is a problem on a wholly different level. XML elements not being comparable without non-local information is not an edge case and not an oversight that can be fixed or worked around. It's by design.

I'm not criticising XML for being what it is. XML tries to solve problems that JSON doesn't try to solve. But in order to do that, it had to introduce complexity that many people now reject.

Edit: I think we're talking past each other here. You are rightly criticising the JSON specification for being sloppy and incomplete. I don't dispute that. I'm comparing the models as they are _intended_ to work. And that's where XML is more complex because it tries to do more.

Re: JSON Schema Store

#122

Post by unilynx »

crabbone wrote: post #116
unilynx wrote: post #82

Earlier quoted context omitted.

JSON and XML both support UTF-8. Neither supports embedding arbitrary binary data directly, especially if that data is not valid in your current character set

You wanted to send zero byte. This is how you send zero byte. You are making unrelated claims now that has nothing to do with your original claim.

You can't safely send zero bytes over XML even with UTF-8 encoding. Not in practice:

  echo '�' | xmllint -
  -:1: parser error : xmlParseCharRef: invalid xmlChar value 0
  �
            ^

  printf '\0' | xmllint -
  -:1: parser error : Premature end of data in tag zero line 1
  
                                            ^
And not in theory: https://www.w3.org/TR/2006/REC-xml11-20060816/#sec-well-form...

  Character Range

  [2]    Char    ::=    [#x1-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */
  [2a]    RestrictedChar    ::=    [#x1-#x8] | [#xB-#xC] | [#xE-#x1F] | [#x7F-#x84] | [#x86-#x9F]

Re: JSON Schema Store

#123

Post by fauigerzigerk »

crabbone wrote: post #118
geysersam wrote: post #54

Earlier quoted context omitted.

I don't understand the problem you're describing. When would using JSON lead to data loss/corruption?

Here's a thing that happened in the wild. Neo4j database encodes ids of stored entities as 128-bit integers and it has a JSON interface. When queried from Python, the Python client interprets digit sequences longer than what could possibly fit into 2^32 as floats (even though the native kind of integer in Python is of arbitrary size). So, for a while there weren't too many objects, ids appeared to be all different...…

>few people are aware that JSON allows key duplication in "hash-tables"

I would say it's the other way around. Many people seem to think that duplicate keys are allowed in JSON, but the spec says "An object is an unordered set of name/value pairs". Sets, by definition, do not allow duplicates.

https://www.json.org/json-en.html

>There are many other things, like, for example, JSON has too many of the "false" values. When different languages generate JSON they may interpret things like "missing key" and "key with the value null" as the same thing or as a different thing. Similarly, for some "false" and "null" are the same thing, while for others it's not.

I don't see how this is a JSON issue. There's only one false value in JSON. If some application code or mapping library is hellbent on misinterpreting all sorts of things as false then there is no way to stop that on a data format level.

What I do agree with is your critcism of how the interpretation of long numbers is left unspecified in the JSON spec. This is just sloppy and should be fixed.

Re: JSON Schema Store

#124

Post by unilynx »

peoplefromibiza wrote: post #109
maskros wrote: post #94

Earlier quoted context omitted.

"\0" is not a valid JSON string escape sequence. However, "\u0000" is.

not according to jq or firefox >> JSON.parse("\u0000") Uncaught SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data debugger eval code:1 at that point "null" looks like a better more compatible option.

they're not comparable at all. you can't embed a null into a string

\u0000 works fine with firefox with the proper syntax

  JSON.parse(`"\\u0000"`)
  "\u0000"
and jq supports it too

  printf '{"null":"\u0000"}' | jq
  {
    "null": "\u0000"
  }

Re: JSON Schema Store

#125

Post by [deleted] »

unilynx wrote: post #124
peoplefromibiza wrote: post #109

Earlier quoted context omitted.

not according to jq or firefox >> JSON.parse("\u0000") Uncaught SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data debugger eval code:1 at that point "null" looks like a better more compatible option.

they're not comparable at all. you can't embed a null into a string \u0000 works fine with firefox with the proper syntax JSON.parse(`"\\u0000"`) "\u0000" and jq supports it too printf '{"null":"\u0000"}' | jq { "null": "\u0000" }

[deleted]

Re: JSON Schema Store

#126

Post by j-pb »

mdaniel wrote: post #120
j-pb wrote: post #92

Earlier quoted context omitted.

I would argue that the inline way of annotating things in XML is actually ok-ish if one absolutely needs human edit-ability, but otherwise bad design. {text: "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.", annotations: [{tag: "sometag", ranges: [{from: 12, to: 26}]}, {tag: "sometothertag", ranges: [{from: 21, to: 39}]} Note that this also…

crafty, but for your consideration: that places the burden upon every library author to be "accounting accurate" to any edits, and the only way anyone would know that it's not correct is to visually inspect the output text also, as I get older I have a deeper and deeper appreciation that "offset" and "text" are words that are fraught with peril

Fair critique, but shouldn't strings be immutable anyways? Once you bring editing into play, you'll probably either want something like a rope or some CRDT and then you have more effective means of tracking positions, than manual offset computations, as part of the data-structure.

Re: JSON Schema Store

#127

Post by vonwoodson »

andyjohnson0 wrote: post #71
seanp2k2 wrote: post #3

JSON is the version of XML we deserve.

Whenever two or more are gathered together, they shall argue about JSON vs XML. Personally I like the simplicity of JSON and also the expressive power of XML. But then I tend to only use each for the task it was primarily intended: application data-on-the-wire in JSON and "documents" in XML. It seems like a lot of the recurrent discussion around these technologies happens when they're pushed to do things outside thei…

I'd extend this "X developers are mostly self-taught" onto all of computer development. They say, "Every developer Of a Certain Age's first programming language was BASIC" and my experience of (eventually) getting a CS degree is that there is the expectation of students to already know how to do the thing that they are trying to teach; a certain level of "self taught" is expected. To that end, I can see how in The Age of Teh Internets that the standard of self taught has moved of from BASIC to HTML/CSS/JS (or Unity or whatever sparked the young mind's attention). --- What I'm not certain of is that "self taught" means that work will be duplicated because the self taught developer doesn't know the technology that exists. I think that someone who is extremely online will very likely be more abreast of what technologies exist. I think that a formal education is better at establishing what the fundamentals underlying a programing method or paradigm... but not necessarily at exposing new programmers to what the state-of-the-art is.

Re: JSON Schema Store

#128

Post by peoplefromibiza »

unilynx wrote: post #124
peoplefromibiza wrote: post #109

Earlier quoted context omitted.

not according to jq or firefox >> JSON.parse("\u0000") Uncaught SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data debugger eval code:1 at that point "null" looks like a better more compatible option.

they're not comparable at all. you can't embed a null into a string \u0000 works fine with firefox with the proper syntax JSON.parse(`"\\u0000"`) "\u0000" and jq supports it too printf '{"null":"\u0000"}' | jq { "null": "\u0000" }

> the proper syntax

of course! I forgot to quote those quotes! (facepalm)

that works. and uses a single byte too.

TIL.

Re: JSON Schema Store

#129

Post by euroderf »

meepmorp wrote: post #101
JodieBenitez wrote: post #68

Lots of comments here about XML vs. JSON... but there are areas where these two don't collide. I'm thinking about text/document encoding (real annotated text, things like books, etc). Even though XML is still king here (see TEI and other norms), some of its limitations are a problem. Consider the following text: Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dol…

A strategy I've seen for dealing the inability of XML to handle overlapping tags, is to treat the tagging as an annotation layer on top of the node with the data: This is some sample text. The start and end are usually byte offsets from the start of the text content in the data node. It still sucks, but at least you could apply the same general stragegy to more than just text data - I've seen it used with audio/video…

It seems klutzy and yet fully in the spirit of XML.

Re: JSON Schema Store

#130

Post by euroderf »

zdragnar wrote: post #31
osigurdson wrote: post #28

It is interesting that people love json (now with schema), but hate XML while loving HTML at the same time. It is all pretty boring and largely the same imo.

The absolute worst bit of XML is the confused implementations. What should be an attribute on a tag, and what should go between tags? Even worse, nothing is sanely typed without an xsd. Different systems will treat the following differently: true versus 1 Some systems require the token "true", others will only treat 1 as the boolean true. For example, MS claims that for exchange ASD boolean values must be integer 1 o…

> What should be an attribute on a tag, and what should go between tags?

I think a good rule of thumb is that attributes are for key/value pairs that are probably not user-visible and definitely not directly user-editable.

Carried to a logical conclusion, this would simplify the auto-creation of form GUIs.

Post reply on HN