Need advice for on creating a new "standard"/"language"

Question

UPDATE: It was suggested in the comments that I create a wiki for this. I have done, you can find it here (should you wish to keep tabs on it and/or contribute).

http://vrs.tomelders.com

I've never worked on anything like this before, so I'm completely winging it.

---

I've never worked on anything like this before, so please

I'm want to work on an open "standard" or "language", or... well, I don't really know what to call it.... to make form validation easier. I'm calling it VRS (Validation Rule Sheets) but at this stage, everything is negotiable.

The idea is to create a sheet of rules, similar to CSS that define how forms should be validated. This will require

1. A Syntax / Specification
2. A VRS Parser to convert the VRS into something useable
3. A VRS Processor to compare the form data against the rules and return a response.
4. A response format.

The benefits of a system like this would be

1. A platform/language agnostic way to define form validations.
2. A cross platform, highly portable way to define form validations.
3. Easy to read, easy to setup, easy to modify.
4. Client side and backend integration.

First things first though. What should the syntax / specification look like.

The way I see this working online is that a VRS file could be specified as a hidden field and the application routes the supplied form data through the VRS processor before processing it.

By way of an example, you could validate the content type of the "name" field would look like this

name {
    content-type: alpha;
}

content-type could be one of three values: alpha, numeric or alpha-numeric.

Hopefully that makes sense. I've never done anything like this before so I'm eager to get other peoples input. Here's as far as I've gotten

------------------------------------------------------------

content-type: (string) alphanumeric | alpha | numeric

Restricts content to either numeric, text or alphanumeric.

------------------------------------------------------------

is-fatal: BOOL

If the rule fails, is it fatal? This could be really useful
for AJAX responses.

------------------------------------------------------------

allow-null: BOOL

wether a field can be empty or not. Good for required fields
and checkboxes 

------------------------------------------------------------

pattern-match: (string) email | url | regex

match the field against a pattern. 

------------------------------------------------------------

field-match: (string) field_name

compares a field to another field. eg: password confirmation

------------------------------------------------------------

greater-than: INT | FLOAT
less-than: INT | FLOAT
within-range: INT | FLOAT, INT | FLOAT

Pretty self explanatory. With regard to strings however, 
the string length is compared against the params.

------------------------------------------------------------

is-unique: (func) connection(host,user,pass), (func) map(table, field)

Check the value against a field in the database to see if
it's unique.

------------------------------------------------------------

date & time validations

This i'm a bit worried about in terms of terminology. I also
want to include dynamic vars in VRS such as

@now
@today
@thisMonth
@thisYear

------------------------------------------------------------

before: STRING | VAR
after: STRING | VAR

Again, self explanatory. Although I'm unsure what the date/time
format should be. UTC?


------------------------------------------------------------

Elapsed Time:

I'm completely stuck on how to handle conditions like
"years elapsed since date is more than 16"

I don't relish the idea of rules as prolix as

years-elapsed-since-now-are-more-than:18;
years-elapsed-since-now-are-less-than:18;

Finally, I'm debating wether devs should be able to specify the errors/warnings in the VRS or should they do that when handling the response?

So, that's a lot to take in and I hope it's clear. My question(s) I guess are

1. Good idea / bad idea?
2. Is this the right kind of syntax?
3. Are there more elegant ways of naming the rules.
4. What's missing.

thanks

---

UPDATE: A few people have stated that this proposed system is a bad idea. If you think so, please provide a scenario in which it wouldn't work. Thinking it's a bad idea is one thing, proving it's a bad idea is another, and I'd like to see proof that it's a bad idea sooner rather than later. If you really think form validation could not be made easier or less tedious, please explain why.

In addition, I'm aware that form validation is not a new issue. However, there is currently no portable, cross platform, cross language solution to address form validation, which is what this proposal is specifically addressing.

Answer 1

I like the idea of putting the error messages in the VRS too. But they should specific to the rule that failed.

Also, you might consider not developing an entirely new "language" but use something like YAML for which parses already exist.

I see this language as being useful as you could use the same VRS for both client- and server-side validation.

PS: This should be community wiki methinks.

Answer 2

1. I suppose it is a good idea, if you can maintain it yourself.

2. Remember, your making the syntax. It's up to you (so long as it looks decent).

3. no, not really. So long as the names are obvious (look like what they are), and aren't too long or confusing, then the're fine.

4. Perhaps you should note default values for the rules when they aren't specified.

Answer 3

1. Good idea / bad idea?

   Generally, this kind of thing is a bad idea. That's what PHP is for.

   What's wrong with http://www.phpformclass.com/ http://www.x-code.com/vdaemon_web_form_validation.php or other PHP form management tools?

2. Is this the right kind of syntax?

   No. What's wrong with PHP? It has good syntax for this kind of thing.

3. Are there more elegant ways of naming the rules.

   Yes. PHP object classes. Numerous Other projects. You're not the first person to validate form input.

4. What's missing.

   Answering the fundamental question: What's wrong with PHP?

   A list of related projects that already do this and specific reasons why your project is better than all the other ones already out there.

Answer 4

It's a good idea, but it will be difficult or impossible to cover 100% of the scenarios explicitly in the VRS. In my experience (which may not be typical), the source for new and complicated validation rules is inexhaustible. Examples:

• Morbidly complex dependencies - If the selected policy is X and its duration is less than Y months and the deductible is between P and Q, then the underwriter can adjust the base premium a maximum of Z%.
• Validations on aggregates that are difficult to pre-compute - Prevent a trader from executing a trade on a particular equity if doing so will bring our total exposure in that equity's industry over X.
• Validations based on external data - Has a customer ordered the same supply-limited item on a sister site? Is your address valid? Can I ship there?
• Deferred/priority execution for expensive validations - Fetching external data can be expensive. Don't even run the validation if a more trivial validation fails.

If you add rules like these to your VRS, you'll eventually end up with a general purpose programming language (which is, I believe, what S.Lott was getting crabby about). Instead, maybe offer a custom validation type. If a validation is custom, the developer provides a server-side and client-side(if appropriate) validation routine and your VRS framework calls them when appropriate.