Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

This syntax will be used inside HTML attributes. Here are a few examples of what I have so far:

<input name="a" conditions="!b, c" />
<input name="b" />
<input name="c" />

This will make input "a" do something if b is not checked and c is checked (b and c are assumed to be checkboxes if they don't have a :value defined)

<input name="a" conditions="!b:foo|bar, c:foo" />
<input name="b" />
<input name="c" />

This will make input "a" do something if bdoesn't have foo or bar values, and if c has the foo value.

<input name="a" conditions="!b:EMPTY" />
<input name="b" />

Makes input "a" do something if b has a value assigned.

So, essentially , acts as logical AND, : as equals (=), ! as NOT, and | as OR. The | (OR) is only needed between values (at least I think so), and AND is not needed between values for obvious reasons :)

EMPTY means empty value, like <input value="" />

Do you have any suggestions on improving this syntax, like making it more human friendly? For example I think the "EMPTY" keyword is not really appropriate and should be replaced with a character, but I don't know which one to choose.

share|improve this question
Are you reinventing regular expressions? Regex uses ^$ (start of input, followed by end of input) for the empty string. – delnan Mar 29 '12 at 14:04
I don't think regular expressions are appropriate in this case. For one thing, the syntax must be extremely simple and easy. – Anna Mar 29 '12 at 14:05
wy do you feel the need to create a programming language on top of XML (a markup language) – ratchet freak Mar 29 '12 at 14:08
well, I'm open to new suggestions :) I didn't find a better place for this... – Anna Mar 29 '12 at 14:13
Whatever you do otherwise, avoid using custom attribute names like conditions that may some day cause confusion with new (standard or browser-specific) attributes that might be added to HTML. Instead, use data- attributes, like data-conditions, as per HTML5 drafts; they are virtually guaranteed to remain unassigned, to be available for “private use.” – Jukka K. Korpela Mar 29 '12 at 14:24
up vote 1 down vote accepted

Symbols as you use are compact, but they are not friendly. If you are aiming this meta language at developers, then I think it is reasonably simple, as it is based upon punctuation familiar to programmers.

But that is not your aim. You appear to be targeting this language at end users or designers, in which case your syntax is not simple at all. They have no background to imply that ! = not, | = OR.

I would think hard about your target market, and try to find a language that they know (CSS perhaps?) and base your metalanguage around the idioms used in a language they are familiar with, or on basic English and Math (or, and, not, =).

While I cannot be sure that this is appropriate for your end users (that is your call, not mine) I would think that something like this would be a better fit for non-programmers. These are re-writes of the exact examples you used.

  • b = FALSE, c = TRUE
  • NOT b = foo OR bar, c = foo (alternately: b = NOT foo, b = NOT bar, c = foo if you don't want to support NOT on the left side of the expression)
  • b = NOT BLANK

You may choose to identify your reserved words differently than CAPS as I used ($or, $blank, $true), but the aim is to be expressive, not compact.

share|improve this answer
the problem with words, is that when I'm parsing the syntax in javascript I'm using .split('keyword'), and I could easily split the string in the wrong place if a input has "or", "not" etc as value. With characters like !,|,: it's easier because input values and names should not contain such characters – Anna Mar 29 '12 at 14:54
Then write a real parser. – tdammers Mar 29 '12 at 15:07
If someone has not written a full parser, then asking them to is not a trivial task. That said, if you want to create a language @Anna, you are going to have to deal with the fact that naive pattern matching will only get you a little way; you will need to deal with creating a full parser eventually. As soon as you roll out version 1, you will have users building complex expressions that break your simple pattern engine. Be ready for the jump to a full parser, because it will need to happen eventually. – Myrddin Emrys Mar 29 '12 at 15:10
This is effectively what RPG does (which was designed, pretty much, for non-technical types). – Clockwork-Muse Mar 29 '12 at 18:22

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.