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.

  • 1
    Are you reinventing regular expressions? Regex uses ^$ (start of input, followed by end of input) for the empty string.
    – user7043
    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
  • 5
    wy do you feel the need to create a programming language on top of XML (a markup language) Mar 29 '12 at 14:08
  • 1
    well, I'm open to new suggestions :) I didn't find a better place for this...
    – Anna
    Mar 29 '12 at 14:13
  • 1
    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.” Mar 29 '12 at 14:24

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.

  • 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
  • 1
    Then write a real parser.
    – tdammers
    Mar 29 '12 at 15:07
  • 2
    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. Mar 29 '12 at 15:10
  • This is effectively what RPG does (which was designed, pretty much, for non-technical types). Mar 29 '12 at 18:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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