In line with Philip Zeyliger on IDL being a good tool for a human to produce
schema.
Key features (IMHO):
- support for includes (killer feature)
- simpler syntax (a *lot* less '{' and '['...)
- simpler comments syntax
I have a toolchain going from IDL to Java + C# classes that wouldn't work using
JSON schema (the many holes in the AVRO C# side not helping either..).
For the current discussion, all logical types have an equivalent, non-ambiguous
representation as far as can tell:
- decimal: string representation ("3.14159265358979323846264338327950288419 ").
The decimal definition provides the necessary information to decode it.
- date: "2017-10-5" (using the C-locale yyyy-MM-dd format)
- time_xx: either long value or text format as defined the specs (hh:mm:dd)
- date: number of text format
(btw, how did we end up with different json/IDL logical names?!?!)
Looks like all logical types have a 'better' human representation as a text
value. Suggest to have an 'encoding' attribute to indicate how the default
value is defined.
{
"type": "bytes",
"logicalType": "decimal",
"precision": 4,
"scale": 2,
"default":"3.151351351",
"default-encoding":"string" // default encoding being 'AVRO' default (e.g.
binary)
}
Frederic Souchu
-----Original Message-----
From: Bridger Howell [mailto:[email protected]]
Sent: vendredi 20 octobre 2017 09:13
To: [email protected]
Subject: Re: (Default) values for logical types in human-readable form
On Thu, Oct 19, 2017 at 9:17 PM, Philip Zeyliger <[email protected]>
wrote:
> I'm shaky on the details here, but shouldn't humans be using the
> *.avdl form of specifying schemas?
Maybe.
As it is, I've seen a good number of open projects that work rely on JSON
schemas (.avsc files).
IDL is really more tailored towards being a convenience for writing protocols.
Schemas come as a nice bonus, but the tools don't really make schemas a
first-class use case.
For example, suppose that I want to use IDL to write schemas and then generate
specific classes for each schema, I could bring in the maven plugin (or any
number of community plugins for other tools) that reads IDL and then writes out
the generated code.
But then would I end up with a few bits of ugliness:
- the schemas have to be wrapped in a made-up protocol
- the generated code includes a generated protocol class I wouldn't care about
- there are language features that are completely unrelated to my use of
schemas - I wouldn't care about errors or messages at all
This process _is_ sufficient for writing schemas, but I think the unneeded
inputs and outputs and unrelated functionality really contribute to a sense
that IDL isn't for writing schemas. If there was a more focused subset of IDL
that mapped directly onto schemas without some of the extra baggage, I think it
would be easier to recommend that as a high-level schema language.
- Bridger Howell
--
The information contained in this email message is PRIVATE and intended only
for the personal and confidential use of the recipient named above. If the
reader of this message is not the intended recipient or an agent responsible
for delivering it to the intended recipient, you are hereby notified that you
have received this message in error and that any review, dissemination,
distribution or copying of this message is strictly prohibited. If you have
received this communication in error, please notify us immediately by email,
and delete the original message.
This email and its content belong to Ingenico Group. The enclosed information
is confidential and may not be disclosed to any unauthorized person. If you
have received it by mistake do not forward it and delete it from your system.
Cet email et son contenu sont la propriété du Groupe Ingenico. L’information
qu’il contient est confidentielle et ne peut être communiquée à des personnes
non autorisées. Si vous l’avez reçu par erreur ne le transférez pas et
supprimez-le.
