From nobody Sun Jan 24 01:46:10 2021 Return-Path: X-Original-To: httpapi@ietfa.amsl.com Delivered-To: httpapi@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CEF3A11A4 for ; Sun, 24 Jan 2021 01:46:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZ7Oe603UZqs for ; Sun, 24 Jan 2021 01:46:05 -0800 (PST) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC8AF3A11D8 for ; Sun, 24 Jan 2021 01:46:04 -0800 (PST) Received: by mail-lj1-x229.google.com with SMTP id f17so11606183ljg.12 for ; Sun, 24 Jan 2021 01:46:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7e+aGseYoPiOLtWCEDjwD35M8PUkHPVFZG5KS+u5Qkc=; b=sQqW9KBdDM41D5/C5VlDIEUNUGgEWcwKMPKUPgWNEGA0cKOSoizXqaY+OuvyM89SfM +6EKFjZvu6NoAS0BMMCJGOqz0JAbUaQlYffLRpfxJCm1W2xPBB1Z7iC8lPwVIAVS6kKV kbX2w9CEhrU4qE61qjnd86eWeGvdkFXLAAC+TOUE93iQ2w5SUJ6DjnF16OPMXGbrwjh6 ZMB+K7cVZa72Dxvp+bK3w0o75eK7lFDNduydzYCRrBcqQeBpj0KJGXB7lLglA753uWKW q3OHr0Psz//gJcgoaBwyXAszDLuVHgz4gBEOFl7uI0qukXivrNOiZ7kjMmEEtUSjjjfL zvog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7e+aGseYoPiOLtWCEDjwD35M8PUkHPVFZG5KS+u5Qkc=; b=IgHwEy5wO4NkluxNfuQ9vobnpV1Thrbr2iQczPaTB+wWDVc0JaAyF1dRRachUGNnnr govWAgVDQ3R/0+Vl0tqlUDH+MlC8YOil54MAhzqUVeBFdnXc+VSCDxYdNO27pCUVT608 m2djdsRExwTvyVLoM2W4Mw3r33KhWnwoHfkNKLqBqq30VPZFKmo4V4g6YKSnQhBOz1aD YaL+9EB2wvdG76Je+4KXExPF0D0ChD3ZDTqhim647onkw8faRIuRFmUh1WziJzhW/PTy cA2q02aOCTQuTCpENYkQRTzkQdnd4e2vxqJOY/yAM13bA4+U27tcgk0IYKUfiD84QsO7 RYUg== X-Gm-Message-State: AOAM531dtQO+foDJJewKrItn5DtCo+gAlMo+Ko0ratFLfV8A4pqDYfNK MhptgnvX5TumNcjYeTPwmcnOkrTrYpWFSoPbB3eiAYwMylc= X-Google-Smtp-Source: ABdhPJxXtAym6aplDWo1WCchi/b82Toc1pA4oA0AQJctknNmsUCm5J5Wso2qjOKAwS68wZw2rJCw9CXb5fjrW+h8ui8= X-Received: by 2002:a2e:b5b5:: with SMTP id f21mr3126ljn.239.1611481562427; Sun, 24 Jan 2021 01:46:02 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Christoph Kappestein Date: Sun, 24 Jan 2021 10:46:02 +0100 Message-ID: To: "httpapi@ietf.org" Cc: Darrel Miller Content-Type: multipart/alternative; boundary="0000000000001738c005b9a24a2d" Archived-At: Subject: Re: [httpapi] Discussion about JSON payloads and code generation X-BeenThere: httpapi@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Building Blocks for HTTP APIs List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jan 2021 09:46:08 -0000 --0000000000001738c005b9a24a2d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Thanks for the feedback. @Jason this is true and I totally understand your concern. I think the difficult part is to define a "core" which works for every use case i.e. code generation, validation, documentation, etc. We should ask what is the common ground of all these specs? In JSON Schema this is probably only the part how documents an= d types are referenced (JSON Path). But thanks for the offer and the great feedback which you have provided, I will also give you an answer at our github issue, if I find the time finally ;) @Darrel the idea sounds great to define the representation of data types. A= t TypeSchema we have defined the following primitive types: - date (rfc3339 full-date) - date-time (rfc3339 date-time) - time (rfc3339 full-time) - duration (ISO 8601) - binary (base64 encoded) We have found that most programming languages have internal object representations for these kinds of types. If we would have an official list with a fitting identifier for a type, then we could also use this identifier at the "format" in JSON Schema/TypeSchema to describe the type. I am wondering whether it would be also possible to describe complex types in such a specification, i.e. that we describe how a list, map or object/struct type could look and is defined through keywords. So I would totally support this effort, since this is basically the reason why we have developed TypeSchema and we would be happy to build upon such a specification. best regards Christoph Am Mo., 18. Jan. 2021 um 11:17 Uhr schrieb Asbj=C3=B8rn Ulsberg < asbjorn@ulsberg.no>: > s=C3=B8n. 17. jan. 2021 kl. 22:17 skrev Darrel Miller > : > > > In the spirit of "do one thing and do it well" we could have different > > specifications for specific use cases, which would be a much more > flexible > > framework than forcing every schema to be a vocabulary. A generator > could then > > support only specific schema types. > > Ulysse Carion has already created a schema language specifically > tailored for code generation with RFC 8927. > > https://www.rfc-editor.org/rfc/rfc8927.html > > -- > Asbj=C3=B8rn Ulsberg -=3D|=3D- asbjorn@ulsberg.no > =C2=ABHe's a loathsome offensive brute, yet I can't look away=C2=BB > --0000000000001738c005b9a24a2d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Thanks for the feedback.

@Jason this is = true and I totally understand your concern. I think the difficult
part i= s to define a "core" which works for every use case i.e. code gen= eration,
validation, documentation, etc. We should ask what is the commo= n ground of all
these specs? In JSON Schema this is probably only the pa= rt how documents and
types are referenced (JSON Path). But thanks for th= e offer and the great
feedback which you have provided, I will also give= you an answer at our github
issue, if I find the time finally ;)
@Darrel the idea sounds great to define the representation of data types. = At
TypeSchema we have defined the following primitive types:
- date (= rfc3339 full-date)
- date-time (rfc3339 date-time)
- time (rfc3339 fu= ll-time)
- duration (ISO 8601)
- binary (base64 encoded)

We ha= ve found that most programming languages have internal object
representa= tions for these kinds of types. If we would have an official list with
a= fitting identifier for a type, then we could also use this identifier at t= he
"format" in JSON Schema/TypeSchema to describe the type.
I am wondering whether it would be also possible to describe complex t= ypes
in such a specification, i.e. that we describe how a list, map or o= bject/struct
type could look and is defined through keywords. So I would= totally support this
effort, since this is basically the reason why we = have developed TypeSchema and
we would be happy to build upon such a spe= cification.

best regards
Christoph


Am Mo., 18. = Jan. 2021 um 11:17=C2=A0Uhr schrieb Asbj=C3=B8rn Ulsberg <asbjorn@ulsberg.no>:
s=C3=B8n. 17. jan. 2021 kl. 22:17 skrev= Darrel Miller
<Darrel.Miller=3D40microsoft.com@dmarc.ietf.org>:

> In the spirit of "do one thing and do it well" we could have= different
> specifications for specific use cases, which would be a much more flex= ible
> framework than forcing every schema to be a vocabulary. A generator co= uld then
> support only specific schema types.

Ulysse Carion has already created a schema language specifically
tailored for code generation with RFC 8927.

https://www.rfc-editor.org/rfc/rfc8927.html

--
Asbj=C3=B8rn Ulsberg=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0-=3D|=3D-=C2= =A0 =C2=A0 =C2=A0 =C2=A0 asbjorn@ulsberg.no
=C2=ABHe's a loathsome offensive brute, yet I can't look away=C2=BB=
--0000000000001738c005b9a24a2d--