Proposal: handling trailing and leading spaces

[frontend_dev]

Very often, I see entries which contain leading or trailing spaces in my projects. These usually occur when copying and pasting data from somewhere else. In almost all cases, these spaces are not desired, and may even cause problems.

So what about including something like this in the JSON schema:

{
    "type": "string",
    "leadingSpaces": false,
    "trailingSpaces": false
}

Of course, this only applies to the type "string".

What do you think?

[Henry Andrews]

You can do this with the "pattern" keyword.

thanks,

-henry

---

From: frontend_dev <kude...@alphanull.de>
To: JSON Schema <json-...@googlegroups.com>
Sent: Friday, April 21, 2017 6:43 AM
Subject: [json-schema] Proposal: handling trailing and leading spaces

--
You received this message because you are subscribed to the Google Groups "JSON Schema" group.
To unsubscribe from this group and stop receiving emails from it, send an email to json-schema...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[frontend_dev]

I know. But I don't want to, for several reasons.

One is that I might use another pattern, and I don't want to mix two completely separate validation concerns into one pattern.

This also would make handling more difficult. For example, my client might want to automatically trim this whitespace. So I would have to manually analyse all patterns, and see if there is such a restriction. Plus, there are several ways to express this in a regex. So how can I reliably assess that indeed there are no such whitespaces allowed?

With explicit keywords, this is much much easier (and more stable & reliable as well).

So I still would propose this.

[frontend_dev]

PS: imho patterns are mighty, but only have limited use anyways.

So what would I tell my users when they entered something wrong? "Invalid Pattern"? Totally useless and confusing for them.

I even went so far that I check for some common patterns used like: ^[0-9]*$

Then, I can tell them: "Only numbers allowed". So then they know what exactly went wrong.

But still, quite clunky and therefore I am rather wary with using patterns.

[Henry Andrews]

You're definitely correct that regexes are not user-friendly.  However there are some other proposals on how to provide better user feedback when it might not be obvious from the actual validator failure.  The most relevant is https://github.com/json-schema-org/json-schema-spec/issues/148

The concern is that there are many, many things that could be expressed about strings more clearly than through patterns, but we would like to keep the set of validation keywords manageable.

Note that you can also do:

"type": "string",

"allOf": [

  {"pattern": "somecontentpattern"},

  {"patterh": "^\S.*\S$"}

]

(or whatever a sane pattern for no leading/trailing whitespace- I haven't had my first cup of tea yet and I'm not claiming regexes are easy to remember)

thanks,

-henry

---

From: frontend_dev <kude...@alphanull.de>
To: JSON Schema <json-...@googlegroups.com>

Cc: andrew...@yahoo.com
Sent: Friday, April 21, 2017 10:23 AM
Subject: Re: [json-schema] Proposal: handling trailing and leading spaces

[frontend_dev]

Yeah, I see your point, but where do you draw the line? I mean also things like minLength could be expressed by regexes.

And even if I would use "allOf", that would actually make my schema more verbose, and I still would have to analyse the regex itself to actually know what the constraint actually is.

That said, I do not mind if there are more keywords. Not only is the parsing and handling much easier, it is also more understandable. If you have a huge bunch of patterns, it is a bit hard to see whats actually going on.

And for many things I tend to use my own custom formats like "credit-card-number", "iban" and so on (these cannot be validated by regexes anyway), but things like trailing spaces are too generic to warrant their own formats.

[frontend_dev]

PS: saw the proposal and I am not sure if thats a good idea to include actual messages there (think of localization).

What might be useful though is to use this (or something similar) just with plain error codes, which then could be translated by the client.

[Henry Andrews]

Localization is addressed further down in the comments to the proposal.

You are certainly welcome to propose your trailing whitespace keywords on the GitHub project.  Discussions here are just discussions, and won't get tracked beyond theoretically being searchable through google.  Not all of the major contributors on GitHub follow the list closely.

thanks,

-henry

---

From: frontend_dev <kude...@alphanull.de>
To: JSON Schema <json-...@googlegroups.com>
Cc: andrew...@yahoo.com

Sent: Friday, April 21, 2017 12:10 PM

Subject: Re: [json-schema] Proposal: handling trailing and leading spaces

PS: saw the proposal and I am not sure if thats a good idea to include actual messages there (think of localization).

What might be useful though is to use this (or something similar) just with plain error codes, which then could be translated by the client.