Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adopt AEP-202: Fields #155

Open
wants to merge 16 commits into
base: main
Choose a base branch
from
52 changes: 52 additions & 0 deletions aep/general/0202/aep.md.j2
Original file line number Diff line number Diff line change
@@ -0,0 +1,52 @@
# Fields

The [`buf.validate.field`][protovalidate] type, through its accompanying
rambleraptor marked this conversation as resolved.
Show resolved Hide resolved
extension `buf.validate.field`, enriches a field's schema beyond the basic
name and type information.
rambleraptor marked this conversation as resolved.
Show resolved Hide resolved

## Guidance

Decorating a field with `buf.validate.field` is only necessary when a field
rambleraptor marked this conversation as resolved.
Show resolved Hide resolved
consistently follows a set pattern.
rambleraptor marked this conversation as resolved.
Show resolved Hide resolved

#### Format Compatibility
rambleraptor marked this conversation as resolved.
Show resolved Hide resolved

Adding a format specifier to an existing, unspecified field **is not** backwards
rambleraptor marked this conversation as resolved.
Show resolved Hide resolved
compatible, *unless* the field in question has always conformed to the format
being specified.
rambleraptor marked this conversation as resolved.
Show resolved Hide resolved

Changing an existing format specifier to a different one in all cases **is not**
rambleraptor marked this conversation as resolved.
Show resolved Hide resolved
backwards compatible.

## Rationale

#### Why add a format specifier?
rambleraptor marked this conversation as resolved.
Show resolved Hide resolved

The format of a primitive-typed field can be critical to its usability. Some
programming languages may convey a specific type format as a standalone type,
as Java does with [UUID][java uuid]. Most have specific structural requirements
that are validated by the service, so conveying the format to the user ahead of
time is critical to their experience.

#### Why discourage primitive equality comparisons?
rambleraptor marked this conversation as resolved.
Show resolved Hide resolved

The text representations of the supported formats have many nuances and
transforming the value into a canonical representation is non-trivial. As such,
aligning implementations between each consumer and each service without any
issue is infeasiable.

#### Why document value normalizations?
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, what guidance does this refer to?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The above guidance should satisfy this rationale.

Copy link
Collaborator

@rofrankel rofrankel Jul 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Which guidance, specifically? As in, which line of the file says to document value normalization? The word "normalization" doesn't appear before line 37.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I wasn't being precise enough about that. It was implicit. I've added some information in the beginning explaining how validators are useful for field normalization and why that process occurs.

Let me know if it isn't precise enough.


While primitive comparison is not recommended for any of the supported formats,
uniform normalization of values is important to set consumer expectations, and
create a user-friendly surface.

#### Why require an RFC or AEP for new formats?
rambleraptor marked this conversation as resolved.
Show resolved Hide resolved

Those formats which are sufficiently standardized to merit an RFC or AEP are
stable enough and widely enough known to be incorporated as a supported value
and see usage in Google APIs. Requiring such extra guidance means that governing
the format specification is not the responsibility of the `buf.validate.field`
enumeration itself.

[protovalidate]: https://github.com/bufbuild/protovalidate/tree/main/proto/protovalidate
7 changes: 7 additions & 0 deletions aep/general/0202/aep.yaml
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
---
id: 202
state: reviewing
slug: fields
created: 2023-01-22
placement:
category: protobuf
Loading