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

131–140 of 150 posts

Re: JSON Schema Store

#131

Post by euroderf »

jillesvangurp wrote: post #98
fauigerzigerk wrote: post #32

Earlier quoted context omitted.

JSON is far simpler because it has no namespaces and no entities. But I think complexity is always 90% culture. It's pretty arbitrary what kind of culture grows around a particular technology.

Neither did XML originally. XML schema was sort of bolted on via some conventions of defining a schema in the root element. The XML 1.0 spec doesn't mention those. XML Schema is a separate standard that came later. Likewise namespaces are a separate specification as well and not part of the XML specification. The XML specification does have Document Type Definitions (DTD), which were sort of inherited from SGML. This…

I like DTDs. For all their weirdness, they solve a problem rather simply. Reminiscent of BNF. (Altho admittedly they are clueless about namespaces and other fancy bolt-ons.)

Re: JSON Schema Store

#132

Post by euroderf »

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…

> XML namespaces .. All complaints about this feature were coming from people discovering it for the first time.

"XML Namespaces: Giving developers the vapors since 1999."

Re: JSON Schema Store

#133

Post by euroderf »

wyldfire wrote: post #14
WirelessGigabit wrote: post #10

Earlier quoted context omitted.

I prefer JSON's strictness. A Boolean cannot be confused for a string. In yaml: country: no Now your country is Boolean(false) Now, I still prefer yaml overall. Also, I hate that GitHub actions don't support anchors.

That's a false dichotomy. JSON could have comments and not be ambiguous like YAML. In fact: there exists a specification called JSON5 which does include comments. But I agree that it would've been nice if it had comments before it achieved a critical mass of adoption.

I've read the opinion that comments were omitted from JSON in order to forestall hacky round-trip conversions to/from other formats (like XML).

Can anyone confirm/deny ?

Re: JSON Schema Store

#134

Post by feoren »

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

What about using inline "floating" checkpoints for the ranges, instead of character indexes?

  {text: "Lorem ipsum {{1}}dolor sit {{2}}amet{{3}}, consectetur{{4}} adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.",
   annotations: [{tag: "sometag", ranges: [{from: 1, to: 3}]},
                 {tag: "sometothertag", ranges: [{from: 2, to: 4}]}

Re: JSON Schema Store

#135

Post by yencabulator »

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…

Now you've lost human editability/readability and could just as well encode that in a non-XML format.

Re: JSON Schema Store

#136

Post by yencabulator »

peoplefromibiza wrote: post #108
darrenf wrote: post #89

Earlier quoted context omitted.

I'm not certain I understand the point you're trying to make regarding `undefined`, or indeed the expectation that `jq` and `JSON.stringify()` follow the same rules. `JSON.stringify()` is documented to behave exactly as you demonstrate, so there's no surprises: undefined, Function, and Symbol values are not valid JSON values. If any such values are encountered during conversion, they are either omitted (when found in…

> undefined, Function, and Symbol values are not valid JSON values that's the point. The official JSON serializer from every broswer vendor and every Node installation produce invalid JSON. Which for the JavaScriptObjectNotation is kinda hilarious. > Expecting `jq` to somehow understand that its input came from Javascript's `JSON.stringify()` I would expect `JSON.stringify` to give an error if trying to serialize som…

For what it's worth, you misread the output. The returned value was not a string, it was an error indicator:

    > JSON.stringify(42)
    '42'
    > JSON.stringify(undefined)
    undefined
    > typeof JSON.stringify(42)
    'string'
    > typeof JSON.stringify(undefined)
    'undefined'

Re: JSON Schema Store

#137

Post by meepmorp »

yencabulator wrote: post #135
meepmorp wrote: post #101

Earlier quoted context omitted.

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…

Now you've lost human editability/readability and could just as well encode that in a non-XML format.

Yep.

In my experience, the traditional solution for editing with these kinds of hacks is to write a buggy piece of shit custom GUI so people can edit documents. That way, the complaints shift away from your lousy data format to your lousy UI. Problem solved!

Re: JSON Schema Store

#138

Post by guideamigo »

WirelessGigabit wrote: post #10
guideamigo wrote: post #8

Earlier quoted context omitted.

I wish it had comments. And for that reason, I prefer yaml.

I prefer JSON's strictness. A Boolean cannot be confused for a string. In yaml: country: no Now your country is Boolean(false) Now, I still prefer yaml overall. Also, I hate that GitHub actions don't support anchors.

This is the only example everyone points out against yaml.

For Json, there are several such syntactic problems. Unnecessary double quotes and only double quotes everywhere. No dangling comma.

Re: JSON Schema Store

#139

Post by mdaniel »

albert_e wrote: post #103

is there a good tool or library to create a JSON Schema manually/programmatically ?

Its autocomplete story is a mess, but https://github.com/Kong/insomnia#readme at least allows one to visualize any schema authored in the document (it generates examples as well as a schema browser). It's possible that other OpenAPI tools behave similarly, I just happen to have the most hand's on with Insomnia

for example:

    openapi: 3.0.0
    info:
      title: this is my title
      description: a long description goes here
      version: v1
    servers:
    - url: http://127.0.0.1:9090
      description: the local server
    paths:
      /thingy:
        get:
          responses:
            "200":
              description: ok
              content:
                application/json:
                  schema:
                    $ref: '#/components/schemas/Thingy'
    components:
      schemas:
        Thingy:
          type: object
          properties:
            alpha:
              type: boolean
as for the "create automatically," I'd guess that's a genuinely hard problem although if your example documents are simple/homogeneous enough you may get away with it

ok:

  [{"alpha": true}, {"alpha":false}]
problematic:

  [
   {"alpha":{"beta": ["charlie", 3.1415, null]}},
   {"alpha":[{"beta":null}]},
   {"alpha": null}
  }

Re: JSON Schema Store

#140

Post by javcasas »

crabbone wrote: post #50
HdS84 wrote: post #34

Earlier quoted context omitted.

XML suffers from too many options and useless bells and whistles. E.g. the attribute vs Parameter topic is a source of confusion, without adding much value, especially if the source and target are object oriented and/ or a relational db. What's the point? Then there are namespaces, sure there are probably lots of places where you need to use them. But I never encountered a place where they are really needed, but beca…

Why is "how hard it is for beginners to understand a concept without reading a reference" a useful metric for measuring anything? So what if it's hard? -- Spend an hour with the reference document, and your problems will go away. In the days when XML was popular I've been more active in several Web forums that helped novice users with particular technology (and that included XML). Not a single confusion about XML nam…

> Why is "how hard it is for beginners to understand a concept without reading a reference" a useful metric for measuring anything? So what if it's hard? -- Spend an hour with the reference document, and your problems will go away.

Or spend 0 hours reading the JSON reference to reach the same result.

Post reply on HN