Declarative Languages With XML Michael D Thomas mdthomasibiblio

Declarative Languages With XML Michael D. Thomas mdthomas@ibiblio. org

What Are We Talking About? n n XML Is Very Popular For Configuration Files Manifest Declarative Languages Also, Configuration Files Often Manifest App. Domain Specific “Mini-Languages” So….

What Are We Talking About? n n n XML configuration files can be a powerful keystone of loosely-coupled, highly configurable software architectures. A solid understanding of declarative & domain -specific “mini-languages” can help you develop better systems. When creating languages with XML, we need to grasp the pros vs. cons of using XML.

Agenda n n Opening Comments Declarative Language Overview Declarative XML Architectural Context Declarative XML Techniques

XML Is… n XML is…. n n n A Meta-Language A Tree-Based Data Structure An Interoperability-Promoting Standard Web Services Thingy Good Resume Fodder

XML As Meta-Language n n n Syntax Defined Structure Defined Parsers & APIs Already Implemented Typing Already Defined (XSD, Others) Focus On Semantics

Different Types Of Languages n Imperative Languages n n n Object-Oriented Languages Procedural Languages Declarative Languages

Imperative Languages n n n What we think of as “programming” Algorithmic approach Compute values, assign to memory locations Java/C++: Carry on the tradition Procedural & OO languages encapsulate low-level operations Provides execution efficiency

Declarative Languages n n “What” vs. “How” Programs provide “What” is required by the specification Imperative languages focus on “How” the solution is implemented Declarative languages focus on “What”

Declarative vs. Imperative n n Declarative: code the specification directly – the computer is an implementation detail Imperative: solve problems on computer’s terms – use sub-routines, OO & garbage collection to make life easier for humans Both Of Value Today’s goal: how to leverage both approaches in the same app. using XML

Contrasting Approaches n n Swing GUI vs. XHTML GUI SQL join vs. programmatic join

XHTML GUI <b><i> Hello, World! </i></b>

Swing GUI Text. Field field = new Text. Field(“Hello, World”); int face = Font. BOLD | Font. ITALIC; t. set. Font(new Font("Times. Roman", face, 16)); panel. add(field);

Software Development: Small Projects On Small Projects, Life Is Simple….

Software Development: Large Projects

Declarative Language Interface

SQL n n n Very successful approach SQL statements are expressions of relational algebra and calculus (Dr E. F. Codd, 1970) Allows developers to think spatially about problems

SQL SELECT ename, dname FROM emp, dept WHERE emp. deptno = deptno

SQL: Algorithmic Approach n n Take the Cartesian product of the two lists Apply the condition to each row If the condition is met, select the interesting data items from that row Add data items to list to return

Imperative Approach To SQL public Sorted. Map intersect. Maps(Sorted. Map seq_1, Sorted. Map seq_2, Condition condition) { Tree. Map intersected. Map = new Tree. Map(); Iterator it_1 = seq_1. values(). iterator(); while (it_1. has. Next()) { Joinable joinable_1 = (Joinable)it_1. next(); Iterator it_2 = seq_2. values(). iterator(); while (it_2. has. Next()) { Joinable joinable_2 = (Joinable)it_2. next(); if (condition. evaluate(joinable_1, joinable_2)) { Joinable joined. Object = condition. merge. Joinables(joinable_1, join intersected. Map. put(joined. Object. get. Key(), joined. Object); } } } return intersected. Map; }

Imperative Approach To SQL public Sorted. Map union. Maps(Sorted. Map seq 1, Sorted. Map seq 2, Condition condition) { //implementation } public Sorted. Map reduce. Map(Sorted. Map seq, Condition condition) { //implementation } public Sorted. Map inverse. Map(Sorted. Map seq, Condition condition) { //implementation } public Sorted. Map sort. Map(Sorted. Map list 1, Comparator comp) { //implementation }

Imperative Approach To SQL public interface Condition { public boolean evaluate(Joinable joinable_1, Joinable joinable_2); public Joinable merge. Joinables(Joinable joinable_1, Joina ble joinable_2); } public interface Joinable { } public Object get. Key();

Declarative XML As User Interface Joiner joiner = new Joiner(); Condition condition 1 = new Sal. Greater. Than(“ 500”); Condition condition 2 = new Dept. No. Join(); Sorted. Map sal. Filter = joiner. reduce. Map(emp. Table, condition 1); Sorted. Map ret. Map = joiner. intersect. Maps(sal. Filter, dept. Table, condition 2);

What Was That? SELECT ename, dname FROM emp, dept WHERE sal > 500 AND emp. deptno = deptno

The O-R Mapping Problem n n n The Object-Relational Mapping Problem Is Often Solved with…. An XML Declarative Language! E. g, a J 2 EE deployment descriptor (Uses language layering – more on that later)

Architectural Context n n XML is tree-based XML syntax is simple, but can be made overly complex Must map XML languages to underlying object model (e. g. , Java reflection) Can layer other languages (e. g. , SQL) in to your XML language

When To Use Declarative XML

XML As User Interface n n Development teams often forget to write use cases for administrators, downstream developers XML declarative languages must be considered as ways to provide user interfaces Documentation, examples important Usability, Learnability issues important

Declarative XML In App. Lifecycle Compile-Time – Best Performance, Least Flexibility • Start-Time – XML Parsed Once, Good Performance, Good Flexibility. App must be restarted or manual refresh to get flexibility • • Run-Time – Can Impact Performance, But Great Flexibility. Web Services Approach

Start-Time Configuration

Runtime Configuration

Language Validation n n Use XML Schema, DTDs for validation For more complex validation: n n n XSLT transformation Programmatic validation But… Far more important to provide good documentation & examples than to provide good validation

Parsing n n n Can use your favorite XML API Make the SAX vs. DOM decision Use binding approach with JAXB

Declarative XML Pattern

Example Usages n n Standard app. configuration files HTTP Frameworks Workflow applications Rules engines

Techniques n n n n Dynamic Binding Imperative vs. Declarative Partitioning Language Layering Mapping Trees Branching Recursion Normalization & Encapsulation

Dynamic Binding Declarative XML States An Object Name That Should Be Used n Struts Example: <form-bean name = “hello. Form” type = “com. mike. Mike. Action. Form”> </form-bean> n Java: Class a. FClass = Class. for. Name(type. Attr); Action. Form a. F =(Action. Form)a. FClass. new. Instance();

Dynamic Binding n n Translation from XML language to object model Pattern: Super-interface that defines an object’s methods to the system, named class in XML defines implementation Using reflection/introspection, can define method calls Careful – can lose the benefits of the strongly typed imperative language

Imperative/Declarative Partitioning n n Some “programming” is in the new declarative language, some in the imperative language Don’t re-invent the wheel! Tempting to put too much complexity in the new declarative language Cost/benefit: Imperative language can provide flexibility through pluggable modules

Language Layering n Other languages can be layered in to your declarative XML Example: n <xsql: query> SELECT ename, sal FROM emp WHERE sal > 500 </xsql: query> n n Also, XPath expressions in XSLT Better than re-inventing a language in XML

Mapping Trees n n XML is tree-based, and is very good and mapping trees Any flowchart, activity diagram or state diagram can be described in XML Can use such XML to drive workflow systems XML forces tree representations, but graphs can also be represented

Branching n Can use the XSLT technique: <xsl: if test=“condition”>. . . </xsl: if> <xsl: choose> <xsl: when>. . . </xsl: when> <xsl: otherwise>. . . </xsl: otherwise> </xsl: choose> n Can also use best-match technique

Best match technique Given inputs such as: var 1=val 1&var 2=val 2&var 3=val 3& n Can have XML such as: n <actions> <action var 1=“val 1” var 2=“val. X”> <execute class=“com. mike. Foo 1”> </action> <action var 3=“val. X”> <execute class=“com. mike. Foo 2”> </action> <action var 3=“val 3”> <execute class=“com. mike. Foo 3”> </actions> n Foo 3 is the best match

Using Document Order n n In previous example, could be possible that there could be a tie Document order can resolve ambiguity As with tree structure, document order can provide semantic meaning Careful – canonical form issues can arise

Input & Output Processing n n Business logic should be separated from presentation logic Business logic can also be de-coupled from inputs and outputs

Iteration n Need for pure iteration is a sign your language is becoming more algorithmic Could be a better domain-specific abstraction to use Don’t forget about recursion

Normalization/Encapsulation n Any programming language that encapsulates is a better language Don’t make the users of your language repeat themselves For anything more complicated than a couple of attributes, allow a way to reuse XML elements that are definitions

Conclusions n n Declarative Languages are a well established programming paradigm XML can help you create your own powerful languages Doesn’t solve all problems. Pros/cons This presentation exposed you to theoretical basis, historical practice and XML specific techniques