Are you still working on / with this?

[algermissen]

Hi,

I was shocked today that a search did not immediately turn up an official RelaxNG variant for JSON. Just your README file :-)

Are you still working on this?

Jan

[eteeselink]

Jan, you're the second person to ask this here in a very short time. I suppose Google indexed this page or something :-) Unfortunately the answer is "not really" - I haven't really been working on this much at all lately.

However, clearly now there is more demand than I had anticipated. What part of RELAX JSON would you want to have the most? A validation checker? Or a formal definition? Converter to something?

[algermissen]

Hi Egbert,

On 04 May 2014, at 09:06, Egbert Teeselink [email protected] wrote:

Jan, you're the second person to ask this here in a very short time. I suppose Google indexed this page or something :-) Unfortunately the answer is "not really" - I haven't really been working on this much at all lately.

However, clearly now there is more demand than I had anticipated. What part of RELAX JSON would you want to have the most? A validation checker? Or a formal definition? Converter to something?

I am mostly interested in it for documentation purposes.

James Snell and I agreed to work on an I-D along the lines of his blog post[1]. While his approach is more in ‘sync’ with RelaxNG compact syntax (which I think makes sense) I will still consider how your ideas fit in.

If we make use of your more concise approach, I’ll make sure you are involved.

Ok?

Jan

[1] https://www.ibm.com/developerworks/community/blogs/jasnell/entry/relax_ng_compact_for_json29?lang=en

—
Reply to this email directly or view it on GitHub.

[eteeselink]

Ah, I hadn't seen that blog post. Nice that someone else has been looking into it as well!

That said, keeping (almost) backward compatibility with RELAX NG is not currently a goal of RELAX JSON. It makes the schema more verbose and, well, if I wanted verbose, JSON Schema is already there for me. :-)

IMHO, the big advantage of this approach (and of RELAX NG Compact over XML Schema likewise) is conciseness and readability. RELAX NG can't really be any more concise than it is because XML is so flexible. JSON is way less flexible, so a schema language can be much simpler.

But, I might be missing a core use case. Can you explain to me why (almost-)compatibility with RELAX NG is important for you? Maybe we can keep our languages in sync by adding some optional syntax (like title: String is a shorthand for pair title { String }), or something like that.

ps. What's an "I-D"?

[algermissen]

On 05 May 2014, at 09:37, Egbert Teeselink [email protected] wrote:

Ah, I hadn't seen that blog post. Nice that someone else has been looking into it as well!

That said, keeping (almost) backward compatibility with RELAX NG is not currently a goal of RELAX JSON. It makes the schema more verbose and, well, if I wanted verbose, JSON Schema is already there for me. :-)

:-)

IMHO, the big advantage of this approach (and of RELAX NG Compact over XML Schema likewise) is conciseness and readability. RELAX NG can't really be any more concise than it is because XML is so flexible. JSON is way less flexible, so a schema language can be much simpler.

Yes, right. One can leverage that lesser flexibility.

But, I might be missing a core use case.

One thing that is missing is simple substitution:

suppose

{
“foo” : {
“a” : 1,
“b” : 2,
“y” : 3,
},
“bar” : {
“a” : 11,
“b” : 33,
“z” : 3,
},
}

I might like to do

FooBar {
foo : Foo
bar : Bar
}

Foo {
ab
y : Number
}

Bar {
ab
z : Number
}

ab =
a : Number
b : Number

Can you explain to me why (almost-)compatibility with RELAX NG is important for you?

Purely for given people one new thing less. But I guess it is not a gib win in the end.

Maybe we can keep our languages in sync by adding some optional syntax (like title: String is a shorthand for pair title { String }), or something like that.

Yes, thought about that, too. However, one would be nicer. I’ll talk to James.

ps. What's an "I-D”?

I-D : Internet-Draft (the pre-RFC thing)

Jan

—
Reply to this email directly or view it on GitHub.

[eteeselink]

Hey!

Cool that you're open to my ideas. Maybe if we get James involved, we can come to a single vision with the three of us! That would be nice.

I'm not much of the spec-authoring-type though, but I've started to reboot my validator tryout again - for version zero, I intend to write a converter to JSON Schema (kind of like Trang for RELAX NG) so people can use the plethora of JSON Schema tooling out there but write schemas in RELAX JSON (or whatever language we end up coming up with).

Good point about the substitutions. It's not in there right now indeed, but an obvious extension. I'm a bit torn as to what's the best way, however.

The way you propose is essentially analogous to how it works in RELAX NG. It's flexible and powerful, I like it. However, the big appeal of JSON is that it meshes really well with how most popular programming languages work: classes and collections. In most OO languages, you reuse code through inheritance or composition, not macro-like substitution. Composition is already supported in the current version, but inheritance is not. We could also realise what you propose with inheritance.

It's only a small difference, I think. JSON object properties are not ordered (they are, of course, in a JSON text stream but coders should not depend on their order because they're often loaded in some hashmap type of structure). Because of this, as far as I can see right now, the difference between substitutions as in your example and, say, some (multiple) inheritance construct, is really nothing but syntax.

E.g. In place of your example, I could also write

Ab {
  a: Number
  b: Number
}

Foo extends Ab {
  y : Number
}

Bar extends Ab {
  z : Number
}

In RELAX NG, this makes little sense, because (using your syntax)

Foo {
  ab
  y : Number
}

is a different thing than

Foo {
  y : Number
  ab
}

But in JSON, these ought to be the same, because ordering does not matter and keys can't be duplicate, so we don't need RELAX NG's expressiveness.

Multiple substitutions, then, can be accomplished with multiple inheritance (or traits, or mixins, or whatever you'd like to call them). A syntax like

A extends B, C, D { .. }

is probably good enough. We'd need a rule for name clashes (last parent wins? invalid schema? invalid schema unless the key has the same value type?), but that's about it.

The big question is then what's most useful for authoring and for documentation. The extends approach is familiar to nearly all programmers. The substitution approach is probably natural to a slightly wider audience, but maps less well to programming concepts. What do you think?

[josephholsten]

@eteeselink got a link to that ID? I've been avoiding the cat-herding of the IETF for a while, but this is something I've wanted long enough I might make an exception.

[algermissen]

Hey Joseph,

progress is slow because we are both just too busy, but the draft is here: https://github.com/jasnell/jsondoc and I am using it with great satisfaction to specify a bunch JSON-based media types (in a client project)

Jan

[josephholsten]

Hi Jan,

No worries about slow progress! I'm just happy someone's tackling this. I'll take a look later today.

[eteeselink]

got a link to that ID?

@josephholsten I'm not sure what you mean here. What, in this context, is "an ID"?

[josephholsten]

"ID" is ietf speak for internet draft. I totally pointed that at the wrong person, I meant to ask @algermissen.

All's well, and thanks for the nice work!

[coderextreme]

I am looking for a way to validate JSON against XSD or RelaxNG and landed here. Any ideas?

[eteeselink]

Hmm, not really. XML has a fundamentally different data model than JSON so you can't one-on-one convert a schema language for XML into a schema language for JSON.

I think your safest bet is converting the input JSON to XML according to some simple rule and then applying your XSD. If such a simple rule exists, of course.

[coderextreme]

Well, certainly Jsonix has made an effort to convert XML XSD to JSON Schema. As to the success of that, that’s up to me to figure out. Jsonix has enabled me to convert X3D to JSON and back to X3D. And it allows for validation of your JSON objects with JSON schema derived from XML Schema.

John

On Oct 31, 2015, at 12:56 AM, Egbert Teeselink [email protected] wrote:

Hmm, not really. XML has a fundamentally different data model than JSON so you can't one-on-one convert a schema language for XML into a schema language for JSON.

I think your safest bet is converting the input JSON to XML according to some simple rule and then applying your XSD. If such a simple rule exists, of course.

—
Reply to this email directly or view it on GitHub #2 (comment).