Module 9

1
Module 9

• Conclusion

2
Conclusions

• Has XML changed the way we build systems?
• NO!!!
• Should it change the way we build systems?
• YES!!!
• (new methods, adaptive algos, languages, )

3
Overview

• What is XML?
• How is XML used today?
• What needs to be done?

4
What is XML?

• Union of contributions from various research
  communities
• OO, PL, Formal Methods, Theory, Document
  Management, Distributed Systems, Databases,
• Familiy of technologies
• XML, Namespaces, Infoset, XML Schema, XQuery,
  XSLT, SOAP, WSDL, Encryption, Signature,
• New Hype
• Students love it, many tools emerging,
• Potentially, start revolution and make the world
  a better place.

5
XML Killer Advantages

• Separate Data from Schema
• Legacy applications, archiving, rapid prototyping
• Interpret the same data differently, EII
• Data is more valuable than code!
• Cover spectrum of unstructured to structured
• pay as you go integration, content management
• Natural language processing
• Mix data, meta-data, code
• Do not burry meta-date in code
• Exploit (evolving) meta-data in code
• Embraces existing best practices
• Autonomy of services, data modelling, declarative
  progr.

6
XML Problems

• Tree not a graph
• Implementation of references is a mess
• (URI, however, important piece of the puzzle)
• Different ways to do the same thing
• Good for poets, bad for engineers
• Unnecessary complexity
• PI, document nodes
• Web Services are very expensive today
• Technology jungle
• Many new standards in a short time
• E.g., XML vs. RDF (how to take the best of both?)
• Some missing pieces
• Tools, full programming language, best practices

7
XQuery vs. SQL
Persistent data
Persistent data
SQL
XQuery
Transacted data
Transacted data
Declarative processing
Declarative processing
XQuery the XML replacement for SQL ? No, its
more likely that in the long term, XQuery will be
the declarative replacement for imperative
programming languages like Java or C.
8
Overview

• What is XML?
• How is XML used today?
• What needs to be done?

9
How is XML used today?

• M2M Inter-application data exchange format
• EAI, Web Services, REST
• M2H Markup for Natural Language
• XHTML, RSS/ATOM, OpenOffice,
• X2X Meta-data
• Semantic Web
• Scientific data, data provenance

10
Inter-application data exchange

• XML is another layer in the application stack
• (see next slide)
• Bottom-up Approach of Evolution
• Driven by software vendors (Microsoft et al.)
• Need not say sorry for the past
• Make with every new layer
• Critical success factor reduce cost
• Is not happening today potential for frustration
• In contrary, adding to technology jungle

11
Web Services conceptual layers
XML Protocol (SOAP) XML Schema validation XSLT/
Xquery evaluation
application logic data validation error
handling caching, replication and distribution
queries and updates integrity constraints triggers
transactions
12
Are killer pros of XML used?

• Separate data from schema? NO!
• SAP publishes iDocs use them or get lost
• Unstructured structured data? NO!
• Schema of RDBS drives the whole architecture
• Mix data, meta-data, code? NO!
• Every tier locked in.

13
Are killer pros useful to reduce cost?

• Separate data from schema? YES!
• Keep data, remove legacy code
• Publish data (e.g., RfX), subscribers pick it up
• Unstructured structured data? Maybe
• Mix data, meta-data, code? YES!
• One model for everything, reduce jungle
• Improve performance, predictability, evolvibility
• Huge potential constrained by old thinking

14
Storage Model for Scientific Data

• Use XML to store and annotate data
• Relational and OO not flexible enough
• Driven by Open-source community, geeks
• Very little
• Critical success factor make it work
• Huge human efforts, little automization
• Right tools not yet available
• People crying for help. No time to evaluate the
  bigger role of XML yet.

15
Can XML help make Science work?

• Separate data from schema? YES!
• Archive data for generations to come
• Be more flexible no need to squeeze into schema
• Data first then schema / interpretation
• Unstructured and structured data? YES!
• Pay as you go along (e.g., identify genes in DNA)
• Mix data, meta-data, code? YES!
• Data provenance, generic data analysis
• Huge potential constrained by lack of

16
Meta-data Management

• Use XML to store schemas, configuration files,
  audit logs,
• WSDL, UDDI, RDF, OWL, your software!
• Not integrated in overall IT infrastructure
• Yet another component, software layer (opaque)
• Old thinking for the same reasons as in
  M2M/WSXML killer advantages not used
• Critical success factors mass individualization
• Time to market
• Scalability software by the masses(move
  customization work from vendor to user)

17
XML good for mass individualization?

• Separate data from schema? YES!
• Data everywhere, interpretation with the
  user(publish globally, act locally)
• Unstructured and structured data? YES!
• Pay as you go along
• Matches working style of humans
• Mix data, meta-data, code? YES!
• Provide generic tools
• Programming using meta-data
• Huge potential research in new architectures,
  apps, and business models needed

18
Overview

• What is XML?
• How is XML used today?
• What needs to be done?

19
What needs to be done?

• Fix XML bugs (XL Project at ETH)
• Simplification take what is useful (ignore the
  rest)
• Add missing pieces (updates, state, sequence, )
• Get rid of layered architectures (XTream Project,
  ETH)
• Unified P2P architecture call it Internet
• One data model XML
• Remove data silo boundaries 1 information space
• Flexible Information Dissemination
• Push pull
• Dynamic data delivery
• Top-down Design
• Find the right abstractions for the user (not
  vendor)

20
The XML information hub

• Dataflow architecture channels and actors
• Declarative specification of actors Rules

output XML feeds
input XML feeds/channels
XML channel stream of XML elements(e.g., RSS
2.0 or Atom)
Request/response
21
An Example Scenario (XTream)
Mail Client (e.g., Thunderbird)
Skype Client
RSS
speech
Control
RSS lookup
RSS
lookup
Contact DB
iMap Server
Skype Listener
22
Danas list of No-nos

• Plethora of data models
• Three tier architectures
• Imperative programming
• Client-server architectures
• Tight schemas
• Updating the data
• Transactions
• Expectations for complete, correct, and coherent
  information
• The importance of request/response
• Cost models

23
Danas list of dos

• XML
• HTTP
• Push information
• P2P
• Single abstract data model
• Single programming paradigm
• Declarative programming (for highly qual.)
• Automatic data/code distribution, optimization,
  caching
• Adaptive algorithms
• Expectation for partial, wrong and inconsistent
  data
• Probabilistic programming
• Record everything that ever happened

24
Conclusions

• Opportunity to change the world
• Hype
• Enough floating around
• Pressure of globalization, everything is in flux
• Good technical foundations
• 30 years of research and experience
• New killer ideas
• But need to play it right
• Take the risk of applying the new ideas
• Take the risk of listening to the user

25

• ltendgt
• ltthanks/gt
• ltquestions/gt
• lt/endgt