1. SDPL 2002Notes 3.2: Document Object Model1 XML 접근과 관련된 자료

2. SDPL 2002Notes 3.2: Document Object Model 2 The Misconceived Web  The original vision of the WWW was as a hyperlinked document-retrieval system.  It did not anticipate presentation, session, or interactivity.  If the WWW were still consistent with TBL's original vision, Yahoo would still be two guys in a trailer.

3. SDPL 2002Notes 3.2: Document Object Model 3 How We Got Here  Rule Breaking  Corporate Warfare  Extreme Time Pressure

4. SDPL 2002Notes 3.2: Document Object Model 4 The Miracle  It works!  Java didn't.  Nor did a lot of other stuff.

5. SDPL 2002Notes 3.2: Document Object Model 5 The Scripted Browser  Introduced in Netscape Navigator 2 (1995)  Eclipsed by Java Applets  Later Became the Frontline of the Browser War  Dynamic HTML  Document Object Model (DOM)

6. SDPL 2002Notes 3.2: Document Object Model 6 Viewing XML  XML is designed to be processed by computer programs, not to be displayed to humans  Nevertheless, almost all current Web browsers can display XML documents –They do not all display it the same way –They may not display it at all if it has errors  This is just an added value. Remember: HTML is designed to be viewed, XML is designed to be used

7. SDPL 2002Notes 3.2: Document Object Model7 Stream Model  Stream seen by parser is a sequence of elements  As each XML element is seen, an event occurs –Some code registered with the parser (the event handler) is executed  This approach is popularized by the Simple API for XML (SAX)  Problem: –Hard to get a global view of the document –Parsing state represented by global variables set by the event handlers

8. SDPL 2002Notes 3.2: Document Object Model8 Data Model  The XML data is transformed into a navigable data structure in memory –Because of the nesting of XML elements, a tree data structure is used –The tree is navigated to discover the XML document  This approach is popularized by the Document Object Model (DOM)  Problem: –May require large amounts of memory –May not be as fast as stream approach Some DOM parsers use SAX to build the tree

9. SDPL 2002Notes 3.2: Document Object Model 9 SAX and DOM  SAX and DOM are standards for XML parsers –DOM is a W3C standard –SAX is an ad-hoc (but very popular) standard  There are various implementations available  Java implementations are provided as part of JAXP (Java API for XML Processing)  JAXP package is included in JDK starting from JDK 1.4 –Is available separately for Java 1.3

10. SDPL 2002Notes 3.2: Document Object Model 10 Difference between SAX and DOM  DOM reads the entire document into memory and stores it as a tree data structure  SAX reads the document and calls handler methods for each element or block of text that it encounters  Consequences: –DOM provides "random access" into the document –SAX provides only sequential access to the document –DOM is slow and requires huge amount of memory, so it cannot be used for large documents –SAX is fast and requires very little memory, so it can be used for huge documents This makes SAX much more popular for web sites

11. SDPL 2002Notes 3.2: Document Object Model11 Parsing with SAX  SAX uses the source-listener-delegate model for parsing XML documents –Source is XML data consisting of a XML elements –A listener written in Java is attached to the document which listens for an event –When event is thrown, some method is delegated for handling the code

12. SDPL 2002Notes 3.2: Document Object Model 12 Callbacks  SAX works through callbacks: –The program calls the parser –The parser calls methods provided by the program parse(...) The SAX parser Program main(...) startDocument(...) startElement(...) characters(...) endElement( ) endDocument( )

13. SDPL 2002Notes 3.2: Document Object Model 13 Problems with SAX  SAX provides only sequential access to the document being processed  SAX has only a local view of the current element being processed –Global knowledge of parsing must be stored in global variables –A single startElement() method for all elements In startElement() there are many “if-then-else” tests for checking a specific element When an element is seen, a global flag is set When finished with the element global flag must be set to false

14. SDPL 2002Notes 3.2: Document Object Model 14 DOM  DOM represents the XML document as a tree –Hierarchical nature of tree maps well to hierarchical nesting of XML elements –Tree contains a global view of the document Makes navigation of document easy Allows to modify any subtree Easier processing than SAX but memory intensive!  As well as SAX, DOM is an API only –Does not specify a parser –Lists the API and requirements for the parser  DOM parsers typically use SAX parsing

15. SDPL 2002Notes 3.2: Document Object Model 15 Document Object Model (DOM)  How to provide uniform access to structured documents in diverse applications (parsers, browsers, editors, databases)?  Overview of W3C DOM Specification –second one in the “XML-family” of recommendations Level 1, W3C Rec, Oct. 1998 Level 2, W3C Rec, Nov. 2000 Level 3, W3C Working Draft (January 2002)  What does DOM specify, and how to use it?

16. SDPL 2002Notes 3.2: Document Object Model 16 DOM: What is it?  An object-based, language-neutral API for XML and HTML documents –allows programs and scripts to build documents, navigate their structure, add, modify or delete elements and content –Provides a foundation for developing querying, filtering, transformation, rendering etc. applications on top of DOM implementations  In contrast to “Serial Access XML” could think as “Directly Obtainable in Memory”

17. SDPL 2002Notes 3.2: Document Object Model 17 DOM structure model  Based on O-O concepts: –methods (to access or change object’s state) –interfaces (declaration of a set of methods) –objects (encapsulation of data and methods)  Roughly similar to the XSLT/XPath data model (to be discussed later)  a parse tree –Tree-like structure implied by the abstract relationships defined by the programming interfaces; Does not necessarily reflect data structures used by an implementation (but probably does)

18. SDPL 2002Notes 3.2: Document Object Model 18 invoice invoicepage name addressee addressdata address form="00"type="estimatedbill" Leila Laskuprintti streetaddresspostoffice 70460 KUOPIO Pyynpolku 1 <invoice> <invoicepage form="00" <invoicepage form="00" type="estimatedbill"> type="estimatedbill"> Leila Laskuprintti Leila Laskuprintti Pyynpolku 1 Pyynpolku 1 70460 KUOPIO 70460 KUOPIO......Document Element NamedNodeMap Text DOM structure model

19. SDPL 2002Notes 3.2: Document Object Model 19 Structure of DOM Level 1 I: DOM Core Interfaces –Fundamental interfaces basic interfaces to structured documents –Extended interfaces XML specific: CDATASection, DocumentType, Notation, Entity, EntityReference, ProcessingInstruction II: DOM HTML Interfaces –more convenient to access HTML documents –(we ignore these)

20. DOM Level 2 –Level 1: basic representation and manipulation of document structure and content (No access to the contents of a DTD)  DOM Level 2 adds –support for namespaces –accessing elements by ID attribute values –optional features interfaces to document views and style sheets an event model (for, say, user actions on elements) methods for traversing the document tree and manipulating regions of document (e.g., selected by the user of an editor) –Loading and writing of docs not specified (-> Level 3) SDPL 2002Notes 3.2: Document Object Model 20

21. DOM Language Bindings  Language-independence: –DOM interfaces are defined using OMG Interface Definition Language (IDL; Defined in Corba Specification)  Language bindings (implementations of DOM interfaces) defined in the Recommendation for –Java and –ECMAScript (standardised JavaScript) SDPL 2002Notes 3.2: Document Object Model 21

22. SDPL 2002Notes 3.2: Document Object Model 22 Document Tree Structure document document.body document. documentElement

23. SDPL 2002Notes 3.2: Document Object Model 23 child, sibling, parent

24. SDPL 2002Notes 3.2: Document Object Model 24 child, sibling, parent

25. SDPL 2002Notes 3.2: Document Object Model 25 child, sibling, parent

26. SDPL 2002Notes 3.2: Document Object Model 26 child, sibling, parent

27. Core Interfaces: Node & its variants SDPL 2002Notes 3.2: Document Object Model 27 Node Comment DocumentFragmentAttr Text Element CDATASection ProcessingInstruction CharacterData EntityDocumentTypeNotation EntityReference “Extended interfaces” Document

28. SDPL 2002Notes 3.2: Document Object Model 28 DOM interfaces: Node invoice invoicepage name addressee addressdata address form="00" type="estimatedbill" Leila Laskuprintti streetaddresspostoffice 70460 KUOPIOPyynpolku 1NodegetNodeTypegetNodeValuegetOwnerDocumentgetParentNode hasChildNodesgetChildNodes getFirstChildgetLastChildgetPreviousSiblinggetNextSibling hasAttributesgetAttributes appendChild(newChild)insertBefore(newChild,refChild)replaceChild(newChild,oldChild)removeChild(oldChild)Document Element NamedNodeMap Text

29. Object Creation in DOM  Each DOM object X lives in the context of a Document: X.getOwnerDocument()  Objects implementing interface X are created by factory methods D.create X (…), where D is a Document object. E.g: –createElement("A"), createAttribute("href"), createTextNode("Hello!")  Creation and persistent saving of Document s left to be specified by implementations SDPL 2002Notes 3.2: Document Object Model 29

30. SDPL 2002Notes 3.2: Document Object Model 30 invoice invoicepage name addressee addressdata address form="00"type="estimatedbill" Leila Laskuprintti streetaddresspostoffice 70460 KUOPIO Pyynpolku 1 DocumentgetDocumentElementcreateAttribute(name)createElement(tagName)createTextNode(data)getDocType()getElementById(IdVal) Node Document Element NamedNodeMap Text DOM interfaces: Document

31. SDPL 2002Notes 3.2: Document Object Model 31 DOM interfaces: Element invoice invoicepage name addressee addressdata address form="00"type="estimatedbill" Leila Laskuprintti streetaddresspostoffice 70460 KUOPIO Pyynpolku 1 ElementgetTagNamegetAttributeNode(name)setAttributeNode(attr)removeAttribute(name)getElementsByTagName(name)hasAttribute(name) Node Document Element NamedNodeMap Text

32. Accessing properties of a Node –Node.getNodeName () for an Element = getTagName() for an Attr: the name of the attribute for Text = "#text" etc –Node.getNodeValue() content of a text node, value of attribute, …; null for an Element (!!) (in XSLT/Xpath: the full textual content) –Node.getNodeType() : numeric constants (1, 2, 3, …, 12) for ELEMENT_NODE, ATTRIBUTE_NODE,TEXT_NODE, …, NOTATION_NODE SDPL 2002Notes 3.2: Document Object Model 32

33. Content and element manipulation  Manipulating CharacterData D : –D.substringData( offset, count ) –D.appendData( string ) –D.insertData( offset, string ) –D.deleteData( offset, count ) –D.replaceData( offset, count, string ) (= delete + insert) SDPL 2002Notes 3.2: Document Object Model 33 Accessing attributes of an Element object E: Accessing attributes of an Element object E: –E.getAttribute( name ) –E.setAttribute( name, value ) –E.removeAttribute( name )

34. Additional Core Interfaces (1)  NodeList for ordered lists of nodes –e.g. from Node.getChildNodes() or Element.getElementsByTagName("name") all descendant elements of type "name" in document order (wild-card "*" matches any element type) SDPL 2002Notes 3.2: Document Object Model 34 Accessing a specific node, or iterating over all nodes of a NodeList : Accessing a specific node, or iterating over all nodes of a NodeList : –E.g. Java code to process all children: for (i=0; i<node.getChildNodes().getLength(); i++) process(node.getChildNodes().item(i));

35. Additional Core Interfaces (2)  NamedNodeMap for unordered sets of nodes accessed by their name: –e.g. from Node.getAttributes()  NodeList s and NamedNodeMap s are "live": –changes to the document structure reflected to their contents SDPL 2002Notes 3.2: Document Object Model 35

36. DOM: Implementations  Java-based parsers e.g. IBM XML4J, Apache Xerces, Apache Crimson  MS IE5 browser: COM programming interfaces for C/C++ and MS Visual Basic, ActiveX object programming interfaces for script languages  XML::DOM (Perl implementation of DOM Level 1)  Others? Non-parser-implementations? (Participation of vendors of different kinds of systems in DOM WG has been active.) SDPL 2002Notes 3.2: Document Object Model 36

37. A Java-DOM Example  A stand-alone toy application BuildXml –either creates a new db document with two person elements, or adds them to an existing db document –based on the example in Sect. 8.6 of Deitel et al: XML - How to program  Technical basis –DOM support in Sun JAXP –native XML document initialisation and storage methods of the JAXP 1.1 default parser (Apache Crimson) SDPL 2002Notes 3.2: Document Object Model 37

38. Code of BuildXml (1)  Begin by importing necessary packages: import java.io.*; import org.w3c.dom.*; import org.xml.sax.*; import javax.xml.parsers.*; // Native (parse and write) methods of the // JAXP 1.1 default parser (Apache Crimson): import org.apache.crimson.tree.XmlDocument; SDPL 2002Notes 3.2: Document Object Model 38

39. Code of BuildXml (2)  Class for modifying the document in file fileName : public class BuildXml { private Document document; public BuildXml(String fileName) { File docFile = new File(fileName); Element root = null; // doc root elemen // Obtain a SAX-based parser: DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance(); SDPL 2002Notes 3.2: Document Object Model 39

40. Code of BuildXml (3) try { // to get a new DocumentBuilder: documentBuilder builder = factory.newInstance(); if (!docFile.exists()) { //create new doc document = builder.newDocument(); // add a comment: Comment comment = document.createComment( "A simple personnel list"); document.appendChild(comment); // Create the root element: root = document.createElement("db"); document.appendChild(root); SDPL 2002Notes 3.2: Document Object Model 40

41. Code of BuildXml (4) … or if docFile already exists: } else { // access an existing doc try { // to parse docFile document = builder.parse(docFile); root = document.getDocumentElement(); } catch (SAXException se) { System.err.println("Error: " + se.getMessage() ); System.exit(1); } /* A similar catch for a possible IOException */ SDPL 2002Notes 3.2: Document Object Model 41

42. Code of BuildXml (5)  Create and add two child elements to root : Node personNode = createPersonNode(document, "1234", "Pekka", "Kilpeläinen"); root.appendChild(personNode); personNode = createPersonNode(document, "5678", "Irma", "Könönen"); root.appendChild(personNode); SDPL 2002Notes 3.2: Document Object Model 42

43. Code of BuildXml (6)  Finally, store the result document: try { // to write the // XML document to file fileName ((XmlDocument) document).write( new FileOutputStream(fileName)); } catch ( IOException ioe ) { ioe.printStackTrace(); } SDPL 2002Notes 3.2: Document Object Model 43

44. Subroutine to create person elements public Node createPersonNode(Document document, String idNum, String fName, String lName) { Element person = document.createElement("person"); person.setAttribute("idnum", idNum); Element firstName = document. createElement("first"); person.appendChild(firstName); firstName. appendChild( document. createTextNode(fName) ); /* … similarly for a lastName */ return person; } SDPL 2002Notes 3.2: Document Object Model 44

45. The main routine for BuildXml public static void main(String args[]){ if (args.length > 0) { String fileName = args[0]; BuildXml buildXml = new BuildXml(fileName); } else { System.err.println( "Give filename as argument"); }; } // main SDPL 2002Notes 3.2: Document Object Model 45

46. Summary of XML APIs  XML processors make the structure and contents of XML documents available to applications through APIs  Event-based APIs –notify application through parsing events –e.g., the SAX call-back interfaces  Object-model (or tree) based APIs –provide a full parse tree –e.g, DOM, W3C Recommendation –more convenient, but may require too much resources with the largest documents  Major parsers support both SAX and DOM SDPL 2002Notes 3.2: Document Object Model 46

47. SDPL 2002Notes 3.2: Document Object Model 47 실제 구현에서 문제점  Event 처리  Bubbling  Memory leaks

48. SDPL 2002Notes 3.2: Document Object Model 48 Trickling and Bubbling  Trickling is an event capturing pattern which provides compatibility with the Netscape 4 model. Avoid it.  Bubbling means that the event is given to the target, and then its parent, and then its parent, and so on until the event is canceled.

49. SDPL 2002Notes 3.2: Document Object Model 49 Why Bubble?  Suppose you have 100 draggable objects.  You could attach 100 sets of event handlers to those objects.  Or you could attach one set of event handlers to the container of the 100 objects.

50. SDPL 2002Notes 3.2: Document Object Model 50 Memory Leaks  Memory management is automatic.  It is possible to hang on to too much state, preventing it from being garbage collected.

51. SDPL 2002Notes 3.2: Document Object Model 51 Memory Leaks on IE 6  Explicitly remove all of your event handlers from nodes before you discard them.  The IE6 DOM uses a reference counting garbage collector.  Reference counting is not able to reclaim cyclical structures.  You must break the cycles yourself.

52. SDPL 2002Notes 3.2: Document Object Model 52 Memory Leaks on IE 6  That was not an issue for page view-driven applications.  It is a showstopper for Ajax applications.  It will be fixed in IE7.

53. SDPL 2002Notes 3.2: Document Object Model 53 Memory Leaks on IE 6  Remove all event handlers from deleted DOM nodes.  It must be done on nodes before removeChild or replaceChild.  It must be done on nodes before they are replaced by changing innerHTML.