Sun's XPRESS language



  •  http://docs.sun.com/source/819-6131/XPRESS.html

    This chapter introduces the basic features of XPRESS, an XML-based expression and scripting language.

    Uh oh

       <cond>
         <and>
           <notnull><ref>accounts[Exchange].firstname</ref></notnull>
           <notnull><ref>accounts[Exchange].lastname</ref></notnull>
         </and>
         <concat>
           <substr>
                <ref>accounts[Exchange].firstname</ref>
                <i>0</i>
                <i>1</i>
            </substr>
           <ref>accounts[Exchange].lastname</ref>
         </concat>
       </cond> 
    

    Yikes



  • The page is from 2 years ago, so hopefully this may have died a silent death.

    In any case, it looks like its purpose is to be embeded in XML documents, so this isn't XML just for the case of XML.

     

     

    Alright, I confess: I once created a language like this to define form validation rules - and the parser was written in VB.Net.I'm not proud.



  • Lots of workflow or domain-specific languages are just some sort of XML schema.  Most of the time, the idea is that a very basic "program" can be managed with a graphical frontend or another tool that's better-suited to the people managing the process.  You could use your own custom objects/data, but then the logic for interpreting them is hardcoded in the frontend, whereas with a standard spec'ed out expression language, the frontend is more or less replaceable.

    Seeing as how you bolded the words XML-based, I'm going to assume that you don't actually have any legitimate complaint here, and that you're just another dead weight bitching about the prevalence of XML.  Get used to it, it's here to stay, whether Google and 37signals use it or not.

    And no, I don't personally use XPRESS, and the scope of it is probably over-generalized, but it would be over-generalized regardless of the specific type of markup used.



  • There's one advantage, though - unlike [url=http://thedailywtf.com/Articles/The_Enterprise_Rules_Engine.aspx]The Enterprise Rules Engine[/url], you don't have to recompile it every time you change it.



  • I'm surprised they didn't go all the way. I mean, accounts[Exchange].firstname could have been made much more XMLy:

    <member>
      <ref>
        <indexOf>
          <ref>accounts</ref>
        <offset>Exchange</offset>
        </indexOf>
      </ref>
      <field>firstName</field>
    </member>

    Because now they are stuck in a spot where you've got a partial parse tree, but still have to do the final bits yourself. Doesn't make sense. Either you make everything nicely readable (!null(accounts[Exchange].firstname) && !null(accounts[Exchange].lastname)) or you write it out all the way and rely on a front-end to do the formatting.



  • @TGV said:

    Because now they are stuck in a spot where you've got a partial parse tree, but still have to do the final bits yourself. Doesn't make sense. Either you make everything nicely readable (!null(accounts[Exchange].firstname) && !null(accounts[Exchange].lastname)) or you write it out all the way and rely on a front-end to do the formatting.

     

    <rant> Exactly what I was thinking. This is a pet-peeve of mine though, since it seems to be a general anti-pattern among XML-based languages. I mean, I think no one denies the fact that XML is far too verbose to be used comfortably in a text editor. However, because of its standardisation, you could edit it pretty swiftly with a smart IDE.

    So now you have two choices as a language designer:
    Either (1): Roll your own concise and intuitive-to-use language but miss out on all the standardized tools.
    Or (2): Base your format fully on XML and accept that it will be cumbersome to code as direct text - but get it supported instantly in many IDEs, tools and editors.

    Naturally, most people seem to choose option (3): Design a strange amalgamation of XML with text content that needs to be parsed again by your own specialized parser - thereby cunningly combining the costs of both option (1) and (2) with the benefits of neither one...

    And then people complain that XML sucks...
    </rant>



  • @PSWorx said:

    Naturally, most people seem to choose option (3): Design a strange amalgamation of XML with text content that needs to be parsed again by your own specialized parser - thereby cunningly combining the costs of both option (1) and (2) with the benefits of neither one...

    You made me laugh there. But there is one extra problem: you possibly need different parsers for different tags, since one tag can contain expression X and another expression Y and a third one the name of a database schema, possibly extended with user name and password, etc. It's not a biggy, but it can cause discomfort at the end of the rectum.



  • @Aaron said:

    Lots of workflow or domain-specific languages are just some sort of XML schema.  Most of the time, the idea is that a very basic "program" can be managed with a graphical frontend or another tool that's better-suited to the people managing the process.  You could use your own custom objects/data, but then the logic for interpreting them is hardcoded in the frontend, whereas with a standard spec'ed out expression language, the frontend is more or less replaceable.

    Seeing as how you bolded the words XML-based, I'm going to assume that you don't actually have any legitimate complaint here, and that you're just another dead weight bitching about the prevalence of XML.  Get used to it, it's here to stay, whether Google and 37signals use it or not.

    And no, I don't personally use XPRESS, and the scope of it is probably over-generalized, but it would be over-generalized regardless of the specific type of markup used.

    There's an article I read a few months ago called "XML Fever", published on the ACM Communications magazine. It basically states that there are a crapload of things being XML-ized just for the sake of using XML. This "language" seems to be one of those cases.

    XML isn't bad by itself, its the shameless abuse of the thing that irks developers, and gives us front page material.



  • @Zecc said:

    The page is from 2 years ago, so hopefully this may have died a silent death.

    I attended training for this a couple months ago. I assure you, it's still live. Regrettably.

    @Zecc said:

    In any case, it looks like its purpose is to be embedded in XML documents, so this isn't XML just for the case of XML.

    Having actually worked with the XML documents in question, I assure you, it is XML for the sake of XML. At least, it is with the XPRESS usage that I'm saddled with.

    The detail you're missing is that the outer XML document is a templating language which is just as inappropriate for XML as XPRESS is.

    Oh, and just to make things extra-special, the editor they've produced for this "eases" the data entry by having a ginormous two-level menu with all of the constructs one might possibly want to use. Selecting one of these menu items inserts into the current document a leading comment, which almost looks useful until you actually read it, followed by the tag, followed by a comment which is, once again, almost but not quite useful, followed by the close tag. Alternatively, if you highlighted something before selecting the menu item, it inserts the first comment and the open tag in front of the highlighted text, and the close tag after the highlighted text. This would almost be helpful, except the size of the ginormous two-level menu is so large that it's difficult to navigate. Also note that the ginormous two-level menu is not limited just to XML code; it can also insert non-XML code, and it further contains links to web documentation on all of the things it can insert. I strongly suspect it also contains additional stuff; I haven't yet explored the full extent of what's in this beast.



  •  That looks very familiar.... oh yeah, it's LISP!

    (cond
        (and (not-null (ref "accounts[Exchange].firstname"))
             (not-null (ref "accounts[Exchange].lastname")))
        (concat
             (substr (ref "accounts[Exchange].firstname") 0 1)
             (ref "accounts[Exchange].lastname")))
    

     Making it real (read: valid) CL or Scheme would be trivial too....



  • @seconddevil said:

     That looks very familiar.... oh yeah, it's LISP!

    (cond
        (and (not-null (ref "accounts[Exchange].firstname"))
             (not-null (ref "accounts[Exchange].lastname")))
        (concat
             (substr (ref "accounts[Exchange].firstname") 0 1)
             (ref "accounts[Exchange].lastname")))
    

     Making it real (read: valid) CL or Scheme would be trivial too....

    Now of course, as XML is a reinvention-of-the-wheel of S-expressions, this is entirely unsurprising.

Log in to reply