XJ: Facilitating XML Processing in Java Written By : Matthew Harren Mukund Raghavachari Oded Shmueli Michael Burke Rajesh Bordawekar Igor Pechtchanski Vivek Sarke Conference: The 14th International World Wide Web Conference (WWW2005), Chiba, Japan, May 10-14, 2005 Karawan Shahla Seminar Lecture 236803
29
Embed
XJ: Facilitating XML Processing in Java Written By : Matthew Harren Mukund Raghavachari Oded Shmueli Michael Burke Rajesh Bordawekar Igor Pechtchanski.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
XJ: Facilitating XML Processing in Java
Written By :
Matthew Harren Mukund Raghavachari
Oded Shmueli Michael Burke
Rajesh Bordawekar Igor Pechtchanski
Vivek Sarke
Conference: The 14th International World Wide Web Conference (WWW2005), Chiba, Japan, May 10-
14, 2005
Karawan Shahla
Seminar Lecture 236803
Agenda
Some files.Main Idea.Introduction to XJ.XJ Type System.XJ Expressions .XJ Updates.XJ Problems.Conclusion
• These assumptions will not hold if the schema is changed– => run-time errors– problems remain, even if we identify nodes by name
• Possible Schema changes:– Allowing a new optional <students> sub-element– Changing the order of the sub-elements
What about reading the numeric value of an
element?
Traditional XML processing(DOM apis)
Assumption: 2nd child has no child elements
Shaping the future
• What XML-related facilities do we want?– Typed XML objects – Seamless translation of a Schema/DTD into a Java
type – Two composition techniques
• XML notation
• Java’s object creation syntax – Two decomposition techniques
• Typed XPath • Typed, named methods/fields
– XPath expressions as first-class-values
XJ: offered solution
Java XJ.
we will over view the constructs offered by XJ.
Available at: http://www.research.ibm.com/xj
XJ Type System
Integration with Schema
• The rationale: 1. An OO program is a collection of class definitions2. A Schema file is a collection of type definitions
• => let’s integrate these definitions
• Any Schema is also an XJ types– The XJ compiler generates a “logical class” for
each such type– Schema file == package name– Using a schema == import schema_file_name;
import technioncatalog.*;
public class Demo2 { public static void main(String[] args) throws Throwable { String x = "Algorithms 1"; int y = 234247; catalog cat = buildCatalog(new catalog.course( <course><points>3</points>
• Problem: resulting type is sometimes not so clear• Two options
– Sequence<T>• If the compiler determines that all result
elements are of type T
– Sequence<XMLObject>• (Otherwise)
• Automatic conversion from a singleton sequence
• Static check of XPath queries– If result is always empty => compile-time error
XPath Semantics
XJ Updates (Introduction)
• XJ provide three kinds of updates: 1) Simple assignment. 2) Bulk assignment. 3) Structural updates.
• XJ updates are chosen to be consistent with Java’s reference semantics.
XJ Updates (syntax and semantics)
Simple Assignment
The XPath expression returns a reference to the existing element to be updated.
Bulk Assignment
The XPath expression denotes a sequence , bulk assignment allows multiple
assignments. Here double the credit points of each course.
public static void changePoint(catalog.course c, int p) {
cat [| //points |] *:= 2;}
public static void changePoint(catalog.course c, int p) {
c [| /points |] = p;}
XJ Updates (syntax and semantics) Structural updates
public static void addCourse(catalog cat) { course c = new course(<course><points>4</points> <number>234111</number><name>Intorduction to CS</name> <teacher>Roy Friedman</teacher></course>); cat.insertAsLast(c);}
Updates may cause cycles, e.g. a class that have more than one parent.
This arises a run time exception.
Ensuring that the root is never inserted into one of it’s descendants.
Why cycles are bad ?
Can you think of a solution ?
XJ Updates Problems : Type Consistency
• Definitions
1. An XML update operation, u, is a mapping over XML values• u: T1 -> T2
2. An update is consistent if T1 = T2
• Ideally, a compile-time error should be triggered for
each inconsistent update in the program
• Unfortunately, this cannot be promised
• The solution: Additional run-time check
Can you think of an example ?
XJ Updates Problems: Covariant subtyping (the problem)
• Covariance: change of type in signature is in the same direction as that of the inheritance
class X { }class A { public void m(X x) { } }
Class X1 extends X { }Class A1 extends A { public void m(X1 x) { } }...A a = new A1(); a.m(new X());
A1.m() is “spoiled”:
Requires only X1 objects
• Java favors type-safety: A method with covariant arguments is considered to be an overloading rather than overriding
– Same approach is taken by C++, C#
• But, covariance is allowed for arrays– Array assignments may fail at run-time
Which method should be invoked: A.m()
or A1.m() ?
(Now let us get back to our technioncatalog schema…)
• A <course> value is also spoiled – It requires unique children: <points>, <name>, etc.
• But, it also has an unspoiled super-class: XMLObject
– All updates to XMLObject are legal at compile-time
• The following code compiles successfully:public static void trick(course c) { XMLObject x = c; points p = new points(<points>4</points>); x.appendAsLast(p); } Run-time error is