flexible, safe, and efficient dynamic generation of html

IBM Research, NY, USA Dynamic Generation of HTML July 13, 2001

Flexible, Safe, and Efficient Dynamic Generation of HTML

Claus Brabrand*Anders Møller, Anders Sandholm, and Michael Schwartzbach

BRICS, University of Aarhus, Denmark*Visiting IBM Research, Hawthorne, NY, USA

Outline

• Introduction

• Dynamic Documents

• Type Safety

• HTML Validation

• Caching

• Form-Field Validation

• Conclusion

Outline

• Introduction

• Type Safety

• HTML Validation

• Caching

• Conclusion

Interactive (Form-Based) Web Services

• Approaches:• Script-Centered• Page-Centered• Session-Centered

”Web servers on which clients can initiate sessions that involve several exchanges of information mediated by HTML forms”.

serverclient Internet

Script-Centered:Perl/CGI

CLIENT INTERNET SERVER

eWebService

restoresubmit

eWebService

restore

Page-Centered:PHP, ASP, JSP, ...

submit

Page-Centered

• Increased level of abstraction:• CGI protocol details abstracted away

• Easy to add dynamics to static pages:•

• Scalability:• Specialized Web server

“Service code embedded in tags and interpreted by specialized Web server”“Service code embedded in tags and interpreted by specialized Web server”

Script- vs. Page-Centered

• As the service complexity increases:– Page-Centered Script-Centered

• A lot of HTML is generated by script elements

• Interesting duality:• Script-centered:

– Default: programming, Escape: printing (print)

• Page-centered:– Default: printing, Escape: programming (<%...

Both:Fundamental Drawbacks!

a_script another_script

<%= $y %>submit

WebService

• Interpretation-based:• Errors at runtime• (Efficiency)

• A service = A collection of scripts/pages!– Implicit control-flow:

• No input / output correspondence:

Language Requirements!

• Compilation-based:• Errors at compile-time• (Efficiency)

• A complete service specification– Explicit control-flow:

• Statically check input / output correspondence

Session-Centered:Mawl and <bigwig>!e

Web Service

restore

one process

show x;

show y;

suspend

resume

submit

What is <bigwig>?

• A high-level domain-specific programming language for developing interactive Web services.

HTMLHTML

CGI ScriptsCGI Scripts

JavaScriptJavaScript

HTTP Auth.HTTP Auth.

Java AppletsJava Applets

CompleteService

Specification

CompleteService

Specification

A collection ofDomain Specific Languages

• C-like core language with• Session-based runtime system• Dynamic documents• Form-field validation• Relational database• Concurrency control• Semantic security• Cryptographic security• Syntactic-level macros

A collection ofDomain Specific Languages

• C-like core language with• Session-based runtime system• Dynamic documents• Form-field validation• Relational database• Concurrency control• Semantic security• Cryptographic security• Syntactic-level macros

Outline

• Introduction

• Type Safety

• HTML Validation

• Caching

• Conclusion

Outline

• Introduction

• Type Safety

• HTML Validation

• Caching

• Conclusion

Dynamically Generated HTML:Current Problems

• Traditionally:• print(...) in Perl/CGI• <% print(...) %> in PHP, ASP, JSP, ...

• Problems:• Forces linear document construction• Intermixes programmer / designer aspects• No input / output correspondence• No static HTML validation• No common fragments caching

Our Solution: HTML documents in <bigwig>

• Templates (1st class, higher-order values):• XML fragments with named gaps:

• Operations:• plug: for document construction• show: for client interaction

<html> Hello <[what]>!</html>

• Plug: exp <[ id = exp ]

• Example:

html hello = <html>Hello <[what]>!</html>;html world = <html><b>World</b></html>;

html h = hello <[what = world];...;

• Show: show exp ;

eshow x;

submitsuspendresume

• Show: show exp ;

• Example:

eshow x;

submitsuspendresume

html h = hello <[what = world];show h;

Show-Receive

• Show: show exp receive[v =f, ...];

eshow x;

f, ...

suspendreceive & resumesubmit

Show-Receive

• Show: show exp receive[v =f, ...];

• Example:string s;html input = <html> Enter email: <input type=”text” name=”email”></html>;

show input receive[s = email];

string s;html input = <html> Enter email: <input type=”text” name=”email”></html>;

show input receive[s = email];

eshow x;

f, ...

suspendreceive & resumesubmit

Example: ”Welcome”

html greeting = <html> Hello <[who]>, welcome to <[what]>.</html>;

html cover = <html> <head><title>Welcome</title></head> <body><[contents]></body></html>;

html h;h = greeting <[who = ”Stranger”];h = h <[what = <html><b>BRICS</b></html>];show cover <[contents = h];

Flexibility: PHP/ASP/JSP

• List of results (e.g. “search engine”):• One template with 10,20,30,

or 40 hardwired server-sidescript elements:

• One template with one big ”generate-all” server-side script element:

script-centered

<% ..1.. %>

...or...

<% ..2.. %>

<% ..20.. %> :

<% for i=1 to N do { ..i.. } %>

Flexibility: <bigwig>

• List of results (e.g. “search engine”):

• List of results (e.g. “search engine”):• Two templates: “layout” and “entry”...

html layout = <html><ul><[items]></ul><html>;html entry = <html><li><[num]><[items]></html>;

• ...and one recursive function: “f”

html f(int n) { if (n == 0) return layout; return f(n-1) <[items = entry <[num = n]];}

• ...and one recursive function: “f”

• Example usage:

html f(int n) { if (n == 0) return layout; return f(n-1) <[items = entry <[num = n]];}

show f(27);show f(27);

Problems?

• “DynDoc”:• Templates with named gaps• Plug and show

Problems?

a_script another_script

<%= $y %>submit

Outline

• Introduction

• Type Safety

• HTML Validation

• Caching

• Conclusion

Outline

• Introduction

• Type Safety

• HTML Validation

• Caching

• Conclusion

Type Safety(in terms of <bigwig>)

• Show/Receive correspondence:

• Gap presence:

html d = <html> Enter email: <input type=“text” name=“email”><html>;

show d receive[s = age];

html hello = <html>Hello <[what]>!<html>;html world = <html><b>World</b></html>;html h;

h = hello <[contents = world];

Static Analysis!

Apply standard, data-flow analysis techniques,but with highly domain-specific lattices

A (5 mins) Crash Course on Data-Flow Analysis

Claus Brabrand*

BRICS, University of Aarhus, Denmark*Visiting IBM Research, Hawthorne, NY, USA

Data-Flow Analysis

• We need 3 things:• A control-flow graph• A lattice• Transfer functions

“Simulate runtime execution at compile-time

using abstract values”

Data-Flow Analysis

• We need 3 things:• A control-flow graph• A lattice• Transfer functions

• Example: “integer constant propagation”

A Control Flow Graph

int x = 1;int y = 3;

if (..) { x = x+2;} else { x <-> y;}...; // x? y?

int x = 1;int y = 3;

if (..) { x = x+2;} else { x <-> y;}...; // x? y?

int x = 1;int x = 1;

int y = 3;int y = 3;

if-else

x = x+2;x = x+2; x <-> y;x <-> y;

...; // x? y?...; // x? y?

true false

A Lattice

• Lattice L of abstract values of interestand their relationships (i.e. ordering “”):

• Induces least-upper-bound operator:(a.k.a. “join”) for joining information

~ “value unknown at C-T!”

~ “we haven’t analyzed yet”

·· -3 -2 -1 0 1 2 3 ··

“top”

“bottom”

Transfer Functions

• For simulating statement computation(on abstract envs, ENVL = VAR L L|VAR|):

• Transfer Function: ENVL ENVL

• Examples:– E . E[y 3]

– E . E[x E(x) L 2]

...where

x = x + 2;x = x + 2;

, if n = m = n L m = , if n = m =

r , o.w. (where r = n + m)

, if n = m = n L m = , if n = m =

r , o.w. (where r = n + m)

Data-Flow Analysis!

if-else

x = x+2;x = x+2; x <-> y;x <-> y;

...; // x? y?...; // x? y?

Data-Flow Analysis!

if-else

x = x+2;x = x+2; x <-> y;x <-> y;

...; // x? y?...; // x? y?

E . E[x 1]

E . E[y 3]

E . E[x E(x) 2]

E . E[x E(y), y E(x)]

Data-Flow Analysis!

if-else

x = x+2;x = x+2; x <-> y;x <-> y;

...; // x? y?...; // x? y?

E . E[x 1]

E . E[y 3]

E . E[x E(x) 2]

E . E[x E(y), y E(x)]

Data-Flow Analysis!

if-else

x = x+2;x = x+2; x <-> y;x <-> y;

...; // x? y?...; // x? y?

E . E[x 1]

E . E[y 3]

E . E[x E(x) 2]

E . E[x E(y), y E(x)]

[ , ] ENVL

[ , ] [ , ][ , ]

Data-Flow Analysis!

if-else

x = x+2;x = x+2; x <-> y;x <-> y;

...; // x? y?...; // x? y?

E . E[x 1]

E . E[y 3]

E . E[x E(x) 2]

E . E[x E(y), y E(x)]

[ 1 , ]

[ , ] [ , ][ , ]

Data-Flow Analysis!

if-else

x = x+2;x = x+2; x <-> y;x <-> y;

...; // x? y?...; // x? y?

E . E[x 1]

E . E[y 3]

E . E[x E(x) 2]

E . E[x E(y), y E(x)]

[ 1 , ]

[ , ] [ , ][ , ]

Data-Flow Analysis!

if-else

x = x+2;x = x+2; x <-> y;x <-> y;

...; // x? y?...; // x? y?

E . E[x 1]

E . E[y 3]

E . E[x E(x) 2]

E . E[x E(y), y E(x)]

[ 1 , ]

[ , ] [ , ][ , ]

[ 1 , 3 ]

Data-Flow Analysis!

if-else

x = x+2;x = x+2; x <-> y;x <-> y;

...; // x? y?...; // x? y?

E . E[x 1]

E . E[y 3]

E . E[x E(x) 2]

E . E[x E(y), y E(x)]

[ 1 , ]

[ , ] [ , ][ , ]

[ 1 , 3 ]

Data-Flow Analysis!

if-else

x = x+2;x = x+2; x <-> y;x <-> y;

...; // x? y?...; // x? y?

E . E[x 1]

E . E[y 3]

E . E[x E(x) 2]

E . E[x E(y), y E(x)]

[ 1 , ]

[ , ][ , ]

[ , ] [ , ][ , ]

[ 1 , 3 ]

Data-Flow Analysis!

if-else

x = x+2;x = x+2; x <-> y;x <-> y;

...; // x? y?...; // x? y?

E . E[x 1]

E . E[y 3]

E . E[x E(x) 2]

E . E[x E(y), y E(x)]

[ 1 , ]

[ , ] [ , ][ , ]

[ 1 , 3 ]

[ 1 , 3 ][ 1 , 3 ]

Data-Flow Analysis!

if-else

x = x+2;x = x+2; x <-> y;x <-> y;

...; // x? y?...; // x? y?

E . E[x 1]

E . E[y 3]

E . E[x E(y), y E(x)]

[ 1 , ]

[ , ] [ , ]

[ 1 , 3 ]

[ 1 , 3 ][ 1 , 3 ]E . E[x E(x) 2]

[ 3 , 3 ]

Data-Flow Analysis!

if-else

x = x+2;x = x+2; x <-> y;x <-> y;

...; // x? y?...; // x? y?

E . E[x 1]

E . E[y 3]

E . E[x E(y), y E(x)]

[ 1 , ]

[ 1 , 3 ]

[ 1 , 3 ][ 1 , 3 ]E . E[x E(x) 2]

[ 3 , 3 ] [ 3 , 3 ]

Data-Flow Analysis!

if-else

x = x+2;x = x+2; x <-> y;x <-> y;

...; // x? y?...; // x? y?

E . E[x 1]

E . E[y 3]

E . E[x E(y), y E(x)]

[ 1 , ]

[ 1 , 3 ]

[ 1 , 3 ][ 1 , 3 ]E . E[x E(x) 2]

[ 3 , 3 ] [ 3 , 3 ]

[ 1 , 3 ]

Data-Flow Analysis!

if-else

x = x+2;x = x+2; x <-> y;x <-> y;

...; // x? y?...; // x? y?

E . E[x 1]

E . E[y 3]

E . E[x E(y), y E(x)]

[ 1 , ]

[ 1 , 3 ]

[ 1 , 3 ][ 1 , 3 ]E . E[x E(x) 2]

[ 3 , 3 ] [ 3 , 3 ]

[ 1 , 3 ]

[ 3 , 1 ]

Data-Flow Analysis!

if-else

x = x+2;x = x+2; x <-> y;x <-> y;

...; // x? y?...; // x? y?

E . E[x 1]

E . E[y 3]

E . E[x E(y), y E(x)]

[ 1 , ]

[ 1 , 3 ]

[ 1 , 3 ][ 1 , 3 ]E . E[x E(x) 2]

[ 3 , 3 ] [ 3 , ]

[ 1 , 3 ]

[ 3 , 1 ]

Fixed-Point!

if-else

x = x+2;x = x+2; x <-> y;x <-> y;

...; // x? y?...; // x? y?

E . E[x 1]

E . E[y 3]

E . E[x E(y), y E(x)]

[ 1 , ]

[ 1 , 3 ]

[ 1 , 3 ][ 1 , 3 ]E . E[x E(x) 2]

[ 3 , 3 ] [ 3 , ]

[ 1 , 3 ]

[ 3 , 1 ]

Fixed-Point Theorem

• One big abstract value vector• [ , , ... , ] (L|VAR|)|PP|

• One big transfer function• F : (L|VAR|)|PP| (L|VAR|)|PP|

• “Fixed-Point Theorem” :• Lattice finite height• Transfer functions monotone

lfp(F) that is computable as: n F n

( PROG ) n F n

( PROG )

[ , ] [ , ] [ , ]

Approximation Only!

• In general: runtime value of an expression, E, is statically undecidable

• Conservatively “err on the safe side”• Sound, but not complete

if ( E ) { ...something good...;} else { ...something bad!...;}/* Here we must assume the worst! */

Type Safety(in terms of <bigwig>)

• Gap presence:

Static Analysis!

• Conservatively approximatefor all HTML variables & program points:

• Their gaps and fields (and their kinds) all possible runtime values

• Forward data-flow analysis:1. Control-flow graph (trivial for <bigwig>)

2. Finite lattice: Gap-and-Field

3. Monotone transfer functions: plug, assign, ...

Gap-and-Field LatticeGKind

string

nofield

checkboxradio

tup(F1)

rel(F1) rel(Fn)

tup(Fn)

• An abstract document is:

(GName GKind) x (FName FKind)

FName FKind

a html

g html

n nogap

GName GKind

a html

g html

n nogap

Monotone Transfer Functions

• Plug: x1 <[g = x2] x1 <[g = x2]

FName FKind

a html

g html

n nogap

FName FKind

a html

g html

n nogap

GName GKind

a nogap

g nogap

n html

GName GKind

a html

g html

n nogap

• Plug: x1 <[g = x2] x1 <[g = x2]

<[g = ]

FName FKind

a html

g html

n nogap

GName GKind

a html

g html

n nogap

FName FKind

a html

g html

n nogap

GName GKind

a nogap

g nogap

n html

FName FKind

a html

g html

n nogap

GName GKind

G : GKind x GKind GKind

• Plug: x1 <[g = x2] x1 <[g = x2]

<[g = ]

FName FKind

a html

g html

n nogap

GName GKind

a html

g html

n nogap

FName FKind

a html

g html

n nogap

GName GKind

a nogap

g nogap

n html

FName FKind

a html

g html

n nogap

GName GKind

a html

• Plug: x1 <[g = x2] x1 <[g = x2]

<[g = ]

FName FKind

a html

g html

n nogap

FName FKind

a html

g html

n nogap

FName FKind

a html

g html

n nogap

GName GKind

a html

g html

n nogap

GName GKind

a nogap

g nogap

n html

GName GKind

a html

g nogap

• Plug: x1 <[g = x2] x1 <[g = x2]

<[g = ]

FName FKind

a html

g html

n nogap

FName FKind

a html

g html

n nogap

FName FKind

a html

g html

n nogap

GName GKind

a html

g html

n nogap

GName GKind

a nogap

g nogap

n html

GName GKind

a html

g nogap

n html

• Plug: x1 <[g = x2] x1 <[g = x2]

<[g = ]

FName FKind

a html

g html

n nogap

FName FKind

a html

g html

n nogap

FName FKind

a html

g html

n nogap

GName GKind

a html

g html

n nogap

GName GKind

a nogap

g nogap

n html

GName GKind

a html

g nogap

n html

Then: Check Solution

• Traverse solution: intercept errors

gap present

E1 <[g = E2]E1 <[g = E2]FName FKind

a html

g html

n nogap

GName GKind

a html

g html

n nogap

gap present

field present

type check: v ~ text

E1 <[g = E2]E1 <[g = E2]

show E receive[v=f, ...];show E receive[v=f, ...];

FName FKind

a html

g html

n nogap

GName GKind

a html

g html

n nogap

GName GKind

a html

g html

n nogap

FName FKind

e radio

f text

t text

Type Safety?

• Gap presence:

Type Safety!

• Gap presence:

*** receive.wig:5: input field ‘email’ not received no such input field ‘age’

*** plug.wig:5: no such gap ‘contents’*** plug.wig:5: no such gap ‘contents’

Problems?

Outline

• Introduction

• Type Safety

• HTML Validation

• Caching

• Conclusion

Outline

• Introduction

• Type Safety

• HTML Validation

• Caching

• Conclusion

Valid HTML !?Valid HTML !?

Static Analysis (again)!

• Conservatively approximatefor all HTML variables & program points:

• A summary graph all possible runtime values

• Forward data-flow analysis:1. Control-flow graph: (trivial for <bigwig>)

2. Finite lattice: summary graphs

3. Monotone transfer functions: plug, assign, ...

Summary Graph

html greeting = ...;

html cover = ...;

Summary Graph

”Stranger”greetingwho

html cover = ...;

Summary Graph

”Stranger”greeting

html cover = ...;

Summary Graph

”Stranger”

greeting

contents who

html cover = ...;

Monotone Transfer Function

• Plug: x1 <[g = x2] x1 <[g = x2]

• Plug:

x1 <[g = x2] x1 <[g = x2]

• Plug:

x1 <[g = x2] x1 <[g = x2]

<[g = ]

• Plug:

x1 <[g = x2] x1 <[g = x2]

<[g = ]

• Plug:

x1 <[g = x2] x1 <[g = x2]

<[g = ]

However, too imprecise!However, too imprecise!

gg<[g = ]

x1 <[g = x2] x1 <[g = x2]• Plug:

open gaps

gg<[g = ]

x1 <[g = x2] x1 <[g = x2]• Plug:

open gaps

GapTrack Analysis

• GapTrack data-flow analysis: program points compute:

• “Tracks the origins (templates) of open gaps”

gg<[g = ]

(g ) (g ) ’

: GName 2TEMPLATES : GName 2TEMPLATES

...;h = greeting <[who = ”Stranger”];h = h <[what = <html><b>BRICS</b></html>];show cover <[contents = h];

• Now: summary graph show statements• Then what...?

Validation?

”Stranger”

greeting

contents who

Validation?

a set of hopeful

XML docs

a set of hopeful

XML docs

A summary graphdescribes:

Validation?

a set of hopeful

XML docs

a set of hopeful

XML docs

a set of valid

XML docs

a set of valid

XML docs

A DTD describes(e.g. XHTML 1.0):

Validation!

a set of hopeful

XML docs

a set of hopeful

XML docs

a set of valid

XML docs

a set of valid

XML docs

validation!

A DTD describes(e.g. XHTML 1.0):

Validation!

a set of hopeful

XML docs

a set of hopeful

XML docs

a set of valid

XML docs

a set of valid

XML docs

validation!

• Decidable!:• Summary graph traversal (parsing vs. DTD)• Memoization termination• Sound and complete!

Compiler Validation Recipe

• Step-by-Step:

1. Extract control-flow graph

2. Gap-and-Field data-flow analysis

3. GapTrack data-flow analysis

4. Summary Graph data-flow analysis

5. Validation (shows) graph analysis

Experiments 800MHz Pentium III / Linux

Program # Lines # Templates Time (sec.)

chat 65 3 0.1

guess 75 6 0.1

calendar 77 5 0.1

xbiff 561 18 0.1

webboard 1132 37 0.6

cdshop 1709 36 0.5

jaoo 1941 73 2.4

bachelor 2535 137 8.2

courses 4465 57 1.3

eatcs 5345 133 6.7

Many validation errors found, no spurious errors

Example Revisited

Planting an Error

html greeting = <html> <td>Hello <[who]>, welcome to <[what]>.</td></html>;

html cover = <html> <head><title>Welcome</title></head> <body><table><[contents]></table></body></html>;

Example Revisited--- welcome.wig:13 HTML Validation:welcome.wig:7 warning: possible illegal subelement ‘td’ of ‘table’ template: <table><[contents]></table> contents: td plugs: contents:{welcome.wig:13}

--- welcome.wig:13 HTML Validation:welcome.wig:7 warning: possible illegal subelement ‘td’ of ‘table’ template: <table><[contents]></table> contents: td plugs: contents:{welcome.wig:13}

123456789

10111213

Problems?

Outline

• Introduction

• Type Safety

• HTML Validation

• Caching

• Conclusion

Outline

• Introduction

• Type Safety

• HTML Validation

• Caching

• Conclusion

Document Representation

document structure

string

document structure

string templates

dynamic

static

dynamic

static

dynamic“Transmit JavaScript recipe for client-side doc. reconstruction”

“Transmit JavaScript recipe for client-side doc. reconstruction”

static

dynamic“Transmit JavaScript recipe for client-side doc. reconstruction”

“Transmit JavaScript recipe for client-side doc. reconstruction”

“Write each template to a separate file so that it can be cached”

Experiments

• Size of HTML: original HTML

JavaScript reconstruction

...all templates cached

Cut to 2.6% – 25% size

Experiments

• Time (download + render) on 700MHz PC, 28.8 Modem:

original HTML

...all templates cached

2.2x – 10x faster

Problems?

Outline

• Introduction

• Type Safety

• HTML Validation

• Caching

• Conclusion

Outline

• Introduction

• Type Safety

• HTML Validation

• Caching

• Conclusion

Example: ”EnterEmail”

html input = <html> Please enter your email:<br> <input type=”text” name=”email”></html>;

html output = <html>Your email is: <[email]></html>;

string s;show input receive[s = email];show output <[email = s];

Example: ”EnterEmail”format Email = regexp(”\w@\w(\.\w)+”);

format Email = regexp(”\w@\w(\.\w)+”);

html input = <html> Please enter your email:<br> <input type=”text” name=”email” format=”Email”></html>;

Form Field Validation: “PowerForms”

• Domain specific language:• uniquely for form-field validation

• Declarative specification (regexps):• Abstracts away operational details

• PowerForms also available as stand-alone tool

PowerFormsPowerFormsHTMLHTML

JavaScript

(subset)

JavaScript

(subset)

HTMLHTML

RegexpsRegexps

Form-Field Interdependency

• “Favorite Letter”• Select filtering

• “NYC Office”• Complex interdependency

Outline

• Introduction

• Type Safety

• HTML Validation

• Caching

• Conclusion

Outline

• Introduction

• Type Safety

• HTML Validation

• Caching

• Conclusion

<bigwig> Dynamic Documents+ Static Analyses:

• Yield: Flexible, Safe, and EfficientDynamic Generation of HTMLFlexible, Safe, and Efficient

Dynamic Generation of HTML

<bigwig> Dynamic Documents+ Static Analyses:

• Yield:

• AND:• Non-linear document construction• Separates programmer / designer aspects• Guaranteed input / output correspondence• Static HTML validation• Common fragments caching

Flexible, Safe, and EfficientDynamic Generation of HTMLFlexible, Safe, and Efficient

Dynamic Generation of HTML

The <bigwig> Compiler

• Version 2.0:• Implemented in C (for UNIX / Linux)• Complete source code available

– Approximately 2.5 MB source

• License: GPL (Gnu Public License)

HTMLHTML

CGI ScriptsCGI Scripts

JavaScriptJavaScript

HTTP Auth.HTTP Auth.

Java AppletsJava Applets

CompleteService

Specification

CompleteService

Specification

<bigwig> Publications

• Concurrency Control ETAPS/FASE, 1998• Runtime System WWW 8, 1999• Dynamic Documents POPL, 2000• Form-Field Validation WWW Journal, 2000• HTML Validation PASTE, 2001• The <bigwig> Project ...submitted, 2001• Syntax Macros ...submitted, 2001• Document Caching ...submitted, 2001• ...

http://www.brics.dk/bigwig/http://www.brics.dk/bigwig/

• Homepage:– Introduction– Examples– Ref. manual– Tutorials– Papers– Presentations– Downloads:

• src / bin

– 72 mins Audio/Video Presentation

The End

flexible, safe, and efficient dynamic generation of html

usa dynamic generation

html documents

html forms

lot of html

static html validation

usaibm research

scriptsubmitibm research

programming ibm research

Documents

flexible html reporting using advanced macro programming and

efficient and flexible technology for binder roving

efficient and flexible algorithm for plant layout generation

flexible • efficient • affordable

more efficient and flexible culture for yeast propagation

based, efficient hygroelectric generator flexible, low...

easy. flexible. efficient. wire processing center

efficient and flexible solution

enabling flexible software-defined energy-efficient

how to build efficient and flexible backup infrastructures

flexible, efficient, economical

‘very efficient’ ‘very flexible’ ‘very...

innovative efficient flexible

thyripol - reliable, efficient, flexible -...

a flexible, computationally efficient method for fitting

flexible test systems for efficient ecu testing

cloud4bizz your business it: secure affordable flexible...

solutions for flexible, efficient and secure satellite-based

comflex–highly efficient and flexible comminution system

ptree: a system for flexible, efficient packet...