Version 2

[tlsa]

• Add union support
• Replace LibYAML
• Add CYAML_CUSTOM type
• Support C99 flexible array members
• Deep clone
• Default values
• Min/max values for integer fields
• General client value validation callback
• Binary type

[ccoustet]

Hi Michael. All these features sound great! I'm currently interested in unions and validation callbacks, but others could be interesting in other projects. Is there already a release timeframe for V2?

[ccoustet]

I don't know if you are interested in suggestions (that is additional work), but I would found very useful to have custom log messages (through callbacks?), including verbose success reporting. And a boolean set/unset for optional fields could be a good feature too.

[ccoustet]

Another feature I would like is to be able to (optionally) store the parsing context of a value. Could be limited to line+column and a pointer to the parent item, all the way up to the top-level item.

[MasterMind2k]

@tlsa, do you have any spec/plan how you intend to implement default values and validation? On project I am working on I've created a small layer to get this in (and is very cumbersome) and I'm interested to help out on this two areas.

[ccoustet]

Hi!
As I see that these topics are discussed, I give my feelings again.
Default values could be solved easily if a set/unset information is added: if the field hasn't been set I can set it with a default value, possibly depending on some read values.
The topic of validation is far more complex. For context-free validation, a simple optional user callback could do the job. The problem is that some constraint can only be checked across a set of fields (if x is true y must be positive). In this case the validation process could only occur post parsing. The lib can help this however by optionally recording some context information that could be used to inform warnings/error messages.

[MasterMind2k]

Validation is a complex topic. First, we should be aware there are two layers of validation. One is input validation (imo, per field) and other is business validation (across fields and in more advanced cases with system state). In my opinion, schema validation should be per field only, to guarantee values in the parsed structure are valid (things like enums, string pattern, etc). Dne, 06. april 2023 10:52:57 GMT+02:00, Christophe Coustet ***@***.***> sporoča:

…

Hi! As I see that these topics are discussed, I give my feelings again. Default values could be solved easily if a set/unset information is added: if the field hasn't been set I can set it with a default value, possibly depending on some read values. The topic of validation is far more complex. For context-free validation, a simple optional user callback could do the job. The problem is that some constraint can only be checked across a set of fields (if x is true y must be positive). In this case the validation process could only occur post parsing. The lib can help this however by optionally recording some context information that could be used to inform warnings/error messages. -- Reply to this email directly or view it on GitHub: #186 (comment) You are receiving this because you are subscribed to this thread. Message ID: ***@***.***>

[ccoustet]

I agree. Complex validation can only be user ad-hoc code.
What I was trying to advocate is that some information is needed to output meaningful messages, like parsing context (e.g. line and column begin end for the field, parent field, ...).

[tlsa]

My current thinking is that I'll add min/max values for validating numerical values.

For mappings I'll add a validation callback option, which will be called on the mapping end event.

What I was trying to advocate is that some information is needed to output meaningful messages, like parsing context (e.g. line and column begin end for the field, parent field, ...).

I don't think that will be necessary. If the client validation callback fails, libcyaml will return a new error code indicating client validation failed, and that will cause the load to abort, and the existing backtrace logging will be used which will contain the position of the mapping that failed to validate. The client itself will have to log what it didn't like about the mapping.

[ccoustet]

The idea behind the context thing is to allow to create meaningful messages from the post-parsing validation step. It has nothing to do with the per-field validation process from within the parsing, that can be kept simple (just because complex validation stuff can be carried out afterwards).I generally like user callbacks when user-guided processing is needed, and I feel its appropriate here (it could be used regardless of the type of field with greater flexibility than range checking). -------- Message d'origine --------De : Michael Drake ***@***.***> Date : 11/04/2023 20:16 (GMT+01:00) À : tlsa/libcyaml ***@***.***> Cc : Christophe Coustet ***@***.***>, Comment ***@***.***> Objet : Re: [tlsa/libcyaml] Version 2 (Issue #186) My current thinking is that I'll add min/max values for validating numerical values. For mappings I'll add a validation callback option, which will be called on the mapping end event. What I was trying to advocate is that some information is needed to output meaningful messages, like parsing context (e.g. line and column begin end for the field, parent field, ...). I don't think that will be necessary. If the client validation callback fails, libcyaml will return a new error code indicating client validation failed, and that will cause the load to abort, and the existing backtrace logging will be used which will contain the position of the mapping that failed to validate. The client itself will have to log what it didn't like about the mapping. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[tlsa]

Default values are now implemented on main.

To use them you need to use the new-style schema building macros.

The old style ones continue to work, they are implemented as wrappers for the new style macros.

It is possible to use the new style macros only for fields that require the new features, for example, the schema in test_load_mapping_field_default_u8.

[tlsa]

Min/max values for integer values is now implemented on main.

[tlsa]

Client value validation callbacks added in this PR: #217. I still need to add tests.

[tlsa]

Validation callbacks are now merged.