Revolution is now LiveCode

Earlier today, RunRev announced the availability of LiveCode 4.5 - the new name and version for the development platform Revolution.

If you've come here and don't know what LiveCode/Revolution is: it is a cross-platform development tool for Windows, MacOSX and Linux, sporting a very-high-level-language that allows you to create working solutions in far less time than other tools and languages. The LiveCode Web browser plug-in works very similar to Flash and Silverlight. There are also pre-releases available of LiveCode Server (comparable to a PHP engine) and LiveCode for iOS (yep, IPhone, iPad and iPod Touch).

Whenever I get a chance, I'll use LiveCode to put together a quick tool for my own use, or a prototype/mockup for something that will eventually be developed in another language like Progress OpenEdge ABL or Java. I also offer Quartam Reports for LiveCode, the essential report generator, and Quartam PDF Library, for those occasions when you need to go beyond 'print to pdf file'.

Where Java is built around a relatively small platform-specific Virtual Machine implementation, with a huge bytecode library on top, LiveCode has a far more optimized yet surprisingly lean core implementation for each supported operating system, and a rich language that means you'll type fewer lines of code to accomplish the same result.

I like the name change and the clearer product line-up. And I like how this new version is faster than ever before. Cheers to the RunRev team for wrapping it up after the setback concerning the iPhone/iPad implementation. Combined with Apple's recent liberation of developer tools, the future looks decidedly LiveCode!

XML validation using a DTD and Versions

In a previous post, I invetigated how we could validate an XML file in revTalk by using a DTD. As we all know, requirements evolve and our software needs to adapt likewise, especially at the integration end-points. So if we need to accept more data, we should (a) know that it's coming, and (b) make sure it's there before we process the incoming data.

How do we do that? Well, as we've seen beofre, we can check the structure of the XML file. And to make sure we check it correctly, we should introduce a specification version for our XML structure, and attach it to the root node of the document as an attribute. Then all we need to do is check the root node, extract its SpecificationVersion attribute, and we can apply the correct DTD validation.

Doesn't sound too complicated, does it? Let's expand our current stack design a bit so that it looks like this:


As you can see, the field "DTD" was renamed to "DTD 1.0" and another field "DTD 1.1" was added to hold the DTD for specification version 1.1; finally, I moved down the "Validate" button and modified its script:

constant kMaxVersion = 1.1

on mouseUp
   -- Load the XML into a local variable
   local tXmlText
   put field "XML" into tXmlText
   -- Parse the XML text into a Tree
   local tXmlTree
   put revCreateXmlTree(tXmlText, \
          false, \
          true,  \
          false) \
          into tXmlTree
   if tXmlTree is not an integer then
      answer error \
             "There is an error in the XML structure" & return & \
             tXmlTree  -- contains the full error message
   else
      -- Validate the root node
      local tRootNode
      put revXmlRootNode(tXmlTree) into tRootNode
      if tRootNode is not "RootNode" then
         answer error \
                "The XML root node should be 'RootNode'"
      else
         -- Validate the SpecVersion
         local tSpecVersion
         put revXmlAttribute(tXmlTree, tRootNode, \
                "SpecificationVersion") into tSpecVersion
         if tSpecVersion begins with "xmlerr" then
            answer error \
                   "The SpecificationVersion is missing"
         else if tSpecVersion > kMaxVersion then
            answer error \
                   "The SpecificationVersion " && tSpecVersion && \
                   "is newer than" && kMaxVersion
         else
            -- Load the corresponding DTD
            local tDtdText
            if tSpecVersion is 1.0 then
               put field "DTD 1.0" into tDtdText
            else
               put field "DTD 1.1" into tDtdText
            end if
            -- Validate the XML against the DTD
            local tValidationResult
            put revXmlValidateDTD(tXmlTree, tDtdText) \
                   into tValidationResult
            if tValidationResult is not empty then
               answer error \
                      "The XML structure does not conform" & \
                      return & tValidationResult
            else
               answer information "The XML conforms to the DTD"
            end if
         end if
      end if
      -- Cleanup
      revDeleteXmlTree tXmlTree
   end if
end mouseUp

So how does this new version work?
- first, it parses the XML document
- next, it verifies the root node
- next, it checks the specification version
- next, it loads the appropriate DTD
- finally, it validates the XML against the DTD

If we test it, it correctly informs us that the XML document conforms to our specification version 1.1. What happens if we change the SpecificationVersion to 1.2?


Then we get this error message:


And finally, what happens if we change the SpecificationVersion to the original 1.0?


Then we get this error message:


This is a much safer way to check the incoming data in XML format. Unfortunately, a Document Type Definition is quite a limited way of XML validation. So next time, we'll improve our defenses again, by incorporating XML Schemas.

XML validation using a DTD

One of the positive aspects of the Extensible Markup Language XML is that it is a flexible way to structure data in a human-readable format, in a cross-platform and technology-independent way. No wonder it is widely used as a way to exchange data between applications, and forms the foundation for XML-RPC, SOAP and other Web Service methods.

But it would be naive to think that every XML document that we get is not only well-formed, but also in the format that we expect it to be, with the right elements and attributes. In this post, we'll examine a strategy to validate incoming XML data in our revTalk application, using a Document Type Definition - a.k.a. DTD.

Part of the XML specification since the very start, a DTD describes the structure of the XML elements and attributes. For more information, I advise you to study the excellent introductory tutorials on W3Schools.com. We're here to use it from revTalk, so let's start by creating a new stack for the user interface.


Simply drop two scrolling fields onto it, name them "XML" and "DTD" respectively, and then group each of them separately so we can put a nice group label on top (I have the memory of a goldfish so I might forget which-is-which ;-) ) Finally drop a button at the bottom of the stack and set its name to "Validate" - and now we're ready to start scripting the button.

First things first, we need to parse the XML text into an XML tree to use all the rev XML commands and functions.

on mouseUp
   -- Load DTD and XML into local variables
   local tDtdText, tXmlText
   put field "DTD" into tDtdText
   put field "XML" into tXmlText
   -- Parse the XML text into a Tree
   local tXmlTree
   put revCreateXmlTree(tXmlText, \
          false, \ -- must be well-formed
          true,  \ -- create a tree in memory
          false) \ -- no SAX parser messages
          into tXmlTree
   if tXmlTree is not an integer then
      answer error \
             "There is an error in the XML structure" & return & \
             tXmlTree  -- contains the full error message
   else
      -- Clean up resources
      revDeleteXmlTree tXmlTree
   end if
end mouseUp

We use the revCreateXmlTree function to parse the XML text into a tree structure. If the XML test is not well-formed then we report the error, otherwise we know we have a valid XML tree structure at our disposal - which we need to cleanup after we're done, using the revDeleteXmlTree command. Now that we have the basics covered, we can add the DTD validation to our script.

on mouseUp
   -- Load DTD and XML into local variables
   local tDtdText, tXmlText
   put field "DTD" into tDtdText
   put field "XML" into tXmlText
   -- Parse the XML text into a Tree
   local tXmlTree
   put revCreateXmlTree(tXmlText, \
          false, \  -- must be well-formed
          true, \ -- create a tree in memory
          false) \ -- no SAX parser messages
          into tXmlTree
   if tXmlTree is not an integer then
      answer error \
             "There is an error in the XML structure" & return & \
             tXmlTree  -- contains the full error message
   else
      -- Validate the XML against the DTD
      local tValidationResult
      put revXmlValidateDTD(tXmlTree, tDtdText) \
             into tValidationResult
      if tValidationResult is not empty then
         answer error \
                "XML structure does not conform to the DTD" & return & \
                tValidationResult  -- contains the full error message
      else
         answer information "The XML conforms to the DTD"
      end if
      -- Clean up resources
      revDeleteXmlTree tXmlTree
   end if
end mouseUp

If the XML conforms to the DTD, the revXmlValidateDtd function will return empty, otherwise its output contains the validation error. Pretty straightforward, so let's test this with a simple XML and DTD:


When we click the 'Validate' button, we get the message that the XML conforms to the DTD. Exactly what we were hoping for. Now let's change the XML somewhat to see if it fails when our XML text clearly does not conform to the DTD.


And here's the error message that we get on our screen:


With very little scripting, we have added a first layer of defense against incoming XML data that is not up to our specifications. Next time, we'll elaborate on this example and bolster our defenses.