Exchanging Intensional XML Data

Exchanging Intensional XML Data

Tova Milo, INRIA & Tel Aviv UniversitySerge Abiteboul, INRIA & Xyleme S.A.Bernd Amann, CNAMOmar Benjelloun, INRIAFrederic Dang Ngoc, INRIA

SIGMOD 2003 – San Diego

Omar Benjelloun - Exchanging AXML Data - SIGMOD 2003

Introduction


Intensional documents Early days of the web

Extensional data (static HTML) CGI scripts (perl, …)

Code is executed to generate data. “Intensional” data

HTML with embedded code (php, jsp, …) Embedded code is executed before sending data.

XML with embedded calls to Web services Calls are still evaluated before sending (Jelly, MX, …).

Active XML Calls do not have to be evaluated before sending data.

Advantages of intensional data More information: it shows how data is generated Dynamic: it provide the means, e.g. to refresh data

Control the exchange of intensional data (to call or not to call?).


Web services in a nutshell

A number of standards XML, SOAP, WSDL, UDDI, …

Means to provide, invoke and describe remote functions with XML input/output.

They make intensional documents exchangeable.


Context: Active XML (AXML)

A language: XML with embedded service calls A peer-to-peer system Each peer

Repository of intensional (AXML) documents Server: provides Web services (XQuery) Client: when invoking the embedded service calls And many more cool features

distribution and replication continuous services etc.

AXML peers exchange intensional data.


Outline

Introduction Intensional data Schema-controlled exchange of intensional data Safe rewriting algorithm Conclusion


Intensional data


GetTemp

city

“Paris”

GetEvents

“Exhibits”

temp

“16°C”

exhibits

GetExhibits

“Paris”

City

Materialization<?xml version=“1.0” ?><newspaper> <title>Le Monde</title> <date>06/10/2003</date> <call svc=“Yahoo.GetTemp”> <city>Paris</city> </call> <call svc=“TimeOut.GetEvents”> exhibits </call></newspaper>

newspaper

titledate

“Le Monde”

“06/10/2003”<temp>16°C</temp>

Y!Y!

Materialization: replacing a service call by its result. It’s a recursive process.

T!T!

<exhibits> <call svc=“Yahoo.GetExhibits”> <city>Paris</city> </call></exhibits>


To call or not to call ?

GetEvents

“Exhibits”

newspaper

title date

“Le Monde”“06/10/2003”

GetTemp

city

“Paris”

temp

“16°C”

Y!Y!

Materialization can be performed by the sender, before sending a document… or by the receiver, after receiving it.

GetEvents

“Exhibits”

newspaper

title date

“Le Monde”“06/10/2003”

GetTemp

city

“Paris”

temp

“16°C”


Why control the materialization of calls? For added functionality, e.g.

Intensional data allows to get up-to-date information. For security reasons or capabilities, e.g.

I don’t trust this Web service/domain, I don’t have the right credentials to invoke it, It costs money, Maybe the receiver doesn’t know Active XML!

For performance reasons, e.g. A proxy can invoke all the services on behalf of a PDA.

… and many more reasons you can think of!


We extend XML Schema, with intensional types: XMLSchemaint

How to control it? Using types

Static analysis algos use signatures of services: WSDLint

... ...

...r

......

...

... ...

g

fq

...

CapabilitiesACLCost...

Sender

Data exchange schema

f qg

CapabilitiesACLCost...

Receiver

gg

g

g

gg

q

q

q

f

fr

r


Schema-controlled exchange


Datanewspaper = title.date.(GetTemp|temp).(GetEvents|

exhibit*)

title = data

date = data

temp = data

city = data

exhibit = title.(GetDate|date)

FunctionsGetTemp(city) -> temp

GetEvents(data) -> (exhibit|performance)*

GetDate(title) -> date

The extended schema language

GetEvents

“Exhibits”

newspaper

title date

“Le Monde”“06/10/2003”

GetTemp

city

“Paris”

Rewriting: replace call(s) by an arbitrary output of the service.

To simplify, we use here a DTD-like syntax


Rewritings

The GoalGiven an intensional document d a schema s, Can we rewrite d so that it matches s?

Safe rewriting: one that for sure leads to s(we know without making any call).

Possible rewriting: one that possibly leads to s (depending on the answer of the service).


Difficulties

Infinite search space Vertical Horizontal

Main problem The result of a Web service call is unknown, We just know a signature (input/output types)

We want a very efficient solution. Foundations of the problem

tree automata, with existential and universal transitions.


Results

Restrictions on the considered rewritings Left-to-right: No “going back and forth” K-depth: bound on the nesting of function calls (Search space still infinite but finitely representable)

Under these restrictions We have algorithms to find safe/possible rewritings. They are PTIME (for deterministic schemas). We can also do it between schemas.

Recent follow-up work by [MSS03] The general problem is undecidable. Some complexity results.


Safe rewriting algorithm



Sketch Deal with function parameters, Traverse the tree top-down, For each data node, rewrite its children.


Rewriting the input parameters of calls To invoke a service, the parameters must

match its signature.

Finish by rewriting the document.

Move recursively upward

Start from the deepest calls



Sketch Deal with function parameters, Traverse the tree top-down, For each data node, rewrite its children.


Rewriting a node’s children

We have The children: title.date.GetTemp.GetEvents The type to match: title.date.temp.(GetEvents|exhibit*) Output types of services:

GetTemp -> temp GetEvents -> (exhibit | performance)*

Three steps Build an FSA that accepts all k-depth rewritings of the word. Build an FSA that recognizes the complement of the type. Compute their intersection to find a safe rewriting.

Smarter algo in the system: lazy automata construction.


accepts all k-depth rewritings of the word.

This is for title.date.GetTemp.GetEvents Output types of services

GetTemp -> temp

GetEvents-> (exhibit | performance)*

GetEvents

Rewriting a node’s children

kwA

1wA

q1title

q6

q2date

q3GetTempq0 q4

q5

q7

exhibit

performance

temp


is the complement automaton for the target type.

Newspaper = title.date.temp.(GetEvents|exhibit*)

Rewriting a node’s children (2)A

p0 p1title

p2date

p3temp

p4GetEvents

p6*

p5

exhibit

exhibit

*

* * * *

*


Rewriting a node’s children (3) AAA k

w

q0,p0 q1,p1 q2,p2 q3,p3 q4,p4

q6,p3q5,p2

q3,p6q7,p6

q4,p6

q7,p6 q7,p3 q4,p3

q7,p5 q4,p5

title date

temp

GetEvents

GetEventsperformance

performance

GetTemp

performance

exhibit

exhibit

exhibit

A safe rewriting exists!

title.date.GetTemp.GetEventstitle.date.temp.GetEvents


Other algorithms (in the paper) Possible rewriting Schema compatibility

Verifies that all instances of a schema safely rewrite to instances of another schema.

Key idea: It is sufficient to check a finite number of instance representatives.


Conclusion

Schema-controlled exchange of intensional data Implemented as part of the Active XML system Fun applications

Easy customization of Web services (VLDB’03 demo)

Types form the basis to match client preferences Surveillance of an AXML application (call tracing)

Perspectives Extend with automatic data conversion Further optimize the algorithm (notably, for simple cases)


Active XML a language and peer-to-peer system based on

XML with embedded calls to Web services VLDB’02 demo SIGMOD session, tomorrow morning http://www-rocq.inria.fr/verso/Gemo/Projects/axml

(or google://ActiveXML) Lots of cool applications

mobile computing, network configuration, warehouse of web resources…

Shameless advertisementShameless advertisement


Merci

Documents

Exchanging Intensional XML Data