Você está na página 1de 21

Web Technology

Unit 5

Unit 5

Structure:

5.1 Introduction Objectives

5.2 XML Objects

5.3 Checking Validity

5.4 Understanding XLinks

5.5 XPointer

5.6 Event-driven Programming

5.7 XML Scripting

5.8 Summary

5.9 Terminal Questions

5.10 Answers

XML Programming

5.1 Introduction

In this unit we will explain the concept of XML object that can be used to eliminate the distinction between the string representation and the object representation of XML documents. After that we will learn about that how we can check the validity of a document and validity with DTD. Then we will learn about XLink and Xpointer. XLink defines a standard way of creating hyperlinks in XML documents whereas; XPointer allows the hyperlinks to point more specific parts in the XML document.

Event Driven Programming is a most useful programming technique used to fire certain control on the fly. The execution of this type of programming is determined by the user actions such as mouse clicks, mouse over, key press etc. At last we will cover XML scripting. XML and scripting languages have a natural relationship since the early days of XML's inception. One of the original goals of the XML design group was to enable a Perl hacker to write an XML parser in two weeks. Handling and manipulating XML has also been fertile ground for using scripting with XML: XML is designed to be human legible, and thus mainly text based. Scripting languages have historically been extremely adept at manipulating text. Scripting's flexibility and power make it a perfect complement to XML's descriptive abilities.

Web Technology

Unit 5

Objectives:

After studying this unit, you will be able to:

define XML objects

explain how to check validity

describe Xlink

define Xpointer

view XML in browser

explain event-driven programming

5.2 XML Object

The main aim of the XML objects is to eliminate the distinction between the string representation and the object representation of XML documents. A web service generating XML or HTML conceptually works only with XML objects. XML structures in a program always denote object structures. It is important that these concepts guarantee validity statically at compile time. XMLObject is a library for reading (not writing) XML. It is particularly suited for cases where one is dealing with small documents of a known structure. XMLObject attempts to make the accessing of small, well-formed XML structures convenient, by providing a syntax that fits well in most Ruby programs.

XML is an extensible markup language. It is extensible because it is meant to define markup languages for any type of document, so new tags are needed depending on the problem domain.

Sometimes, however, XML ends up being used to solve a much simpler problem: the issue of passing a data-structure over the network, and/or between two different languages.

Features & Problems i) Adapters XMLObject supports different adapters to do the actual XML parsing. It ships with REXML (supports both tree and stream document parsing.), and LibXML adapters. By default, the REXML adapter is used. To use a different adapter than the REXML default:

require 'xml-object' require 'xml-object/adapters/libxml'

# Require XMLObject first

Web Technology

Unit 5

ii) Access to elements and attributes

XMLObject uses dot notation (foo.bar) for both elements and attributes, with a few rules, and with an array notation fallback for invalid method names or other tricky situations. For example, with the given file:

Example: <outer object_id="root" name="foo"> <name>Outer Element</name> </outer>

iii) Question notation Elements or attributes that look like booleans are “booleanized” if called by their question names.

iv) Collection auto-folding

XMLObject folds same-named elements found at the same level, like so:

<student>

<name>Bob</name>

<course>Math</course>

<course>Biology</course>

</student>

student = XMLObject.new(xml_file)

student.course.is_a?(Array)

=> true

student.course.first == 'Math'

=> true

student.course.last == 'Biology => true

v) Collection pluralisation

With the same file as in the example above:

student.courses.first == student.course.first => true

Note that the pluralization algorithm is just tacking an ’s’ at the end of the singular, unless ActiveSupport is installed, in which case you get proper plurals, as well as the ability to teach the Inflector about new ones.

vi) Collection proxy

Sometimes, collections are expressed with a container element in XML:

<author> <name>John</name> <publications> <book>Math 101</book>

Web Technology

Unit 5

<book>Biology 101</book> </publications> </author>

In this case, since the container element courses have no text element of its own (attributes are ok), and it only has elements of one name under it, it delegates all methods to the collection below, so you get:

author.publications == author.publications.books => true

author.publications.map { |b| b.downcase } => ['math 101', 'biology 101']

vii) Recursive The design of the adapters assumes parsing of the objects recursively. Deep files are bound to throw SystemStackError, but for the kinds of files I need to read, things are working fine so far. In any case, stream parsing is on the TODO list.

viii) Incomplete It most likely doesn’t work with a ton of features of complex XML files (see the caveats section). I’ll always try to accommodate those, as long as they don’t make the basic usage more complex. As usual, patches welcome.

Self Assessment Questions

1. XMLObject uses

2. XML is an extensible markup language. (True/false)

notation for both elements and attributes.

5.3 Checking Validity

In unit 4 we have already discussed about DTD concept. A DTD defines the legal building blocks of an XML document. It defines the document structure with a list of legal elements and attributes. Basically it talks about the document validity and check the validity of a document that it is valid or not.

Well Formed vs. Valid Well formed in relation to XML means that it has no syntax, spelling, punctuation, grammar errors, etc. in its markup. These kinds of errors can cause your XML document to not parse.

When we think about an XML document is valid, we are saying that the element structure and markup of the XML document matches a defined standard of relationships, in addition to having well formed markup.

Web Technology

Unit 5

DTD and XML schema are XML standards and useful when dealing with the creation of a number of XML documents for they provide a quality control measure to ensure that all the documents meet a minimum standard. Another benefit is that it allows for errors to be detected in the process of creating the XML document, rather than at the end. Later, we'll create a sample DTD for our email and letter XML documents.

When a document is valid it is also "well formed," but a "well formed" document is not necessarily valid. Additionally, we can create XML documents without a DTD, but the XML document can't be considered valid without a document type.

Validating with a DTD Linking your XML document to a DTD Now that we've created a DTD for an XML document, we need to link the XML to the DTD. This takes place in the prolong of the XML document.

Remember that the prolong starts off with the XML declaration:

<?xml version="1.0" encoding="iso-8859-1"?>

Immediately following the XML declaration, we would then either link to a DTD or write an internal DTD. While DTDs can be both internal and external, if we are using a DTD for multiple documents, it makes more sense to have the DTD in a separate "external" file. Otherwise, we will have to put the full DTD in the prolong of every XML document, rather than just one line of code.

To link to an external DTD, the declaration goes like this:

<!DOCTYPE RootElementName SYSTEM "DTDfileLocation">

SYSTEM in the DTD declaration can be replaced by PUBLIC if the DTD is available via the Internet. we would then need to have a public name for the DTD in the file. For example,

Strict//EN"

<!DOCTYPE

"http://www.manipal.com/TR/xhtml1/DTD/xhtml1-strict.dtd">

Assuming that the DTD file we created was in the same folder as our XML files for our email and letters, we would add the following line to the XML code:

html

PUBLIC

"-//manipal//DTD

XHTML

1.0

Web Technology

Unit 5

<!DOCTYPE message SYSTEM "file.dtd">

Element and attribute declaration Now that we have the XML linked, we'll need a full parser to validate the XML files. While most browsers can check for well formed XML, only Internet Explorer 5.0 and higher has a complete XML parser built in to the program that checks against DTDs. we can also use programs such as Dreamweaver, Cooktop, and a variety of other XML authoring software.

An internal DTD is located in the same place as a link to an external DTD but follows the following structure.

<!DOCTYPE rootElement [Element and attribute declarations go here between the brackets ]>. Figure 5.1 is showing how we can declare elements and attributes using DTD.

how we can declare elements and attributes using DTD. Figure 5.1: Example of Element and Attribute

Figure 5.1: Example of Element and Attribute Declaration

To link to a DTD on the Internet, we first need to have an account that can

serve items to the web, such as an manipal account. Then we would need to link to the external DTD with the full URL address. So if we were hosting file.dtd in our personal manipal account, its link would appear as the

<!DOCTYPE message SYSTEM

following:

http://www.manipal.edu/~youraccountname/file.dtd >.

Hopefully, we now feel comfortable creating some basic XML and DTD documents. For more resources on XML and DTDs and XML editors, continue on.

Well Formed XML Documents must have:

XML documents must have a root element

XML elements must have a closing tag

XML tags are case sensitive

XML elements must be properly nested

Web Technology

Unit 5

XML attribute values must be quoted

Example <?xml version="1.0" ?> <note> <to>MyMail</to> <from>OfficeMail</from> <heading>Message</heading> <body>send message from my office mail to my mail.</body> </note>

Valid XML Documents A "Valid" XML document is a "Well Formed" XML document, which also conforms to the rules of a Document Type Definition (DTD):

<?xml version="1.0" "?> <!DOCTYPE note SYSTEM "Note.dtd"> <note>

<to>MyMail</to> <from>OfficeMail</from> <heading>Message</heading> <body>send message from my office mail to my mail.</body> </note>

The DOCTYPE declaration in this example is a reference to an external DTD file.

Self Assessment Questions

if the DTD

3. SYSTEM in the DTD declaration can be replaced by is available via the Internet.

4. When a document is valid it is also "

,"

but a "well formed"

document is not necessarily valid.

5. Well formed in relation to XML means that it has no syntax, spelling, punctuation, grammar errors, etc. in its markup. (True/False)

5.4 Understanding Xlink

Xlink has one job that is to create and define relationships between documents and other resources on the Internet through a system of hypertext links. The Xlink specification uses XML syntax to create sets of

Web Technology

Unit 5

instructions that describe links between resources. Xlinks can be used to define every type of link from a simple <a> link within an HTML document to a more sophisticated link allowing us to select between different documents, based upon everything from language support in out XML browsing software to the current playing time of a video file. Xlink’s entire linking system is based upon the concept of resources. Here a resource is an item, whether a full document or part of one, that can be referenced by a URI (uniform resource identifier). Xlink brings with it the introduction of some new vocabulary: Traversal, arc and behaviour.

Traversal: It is any interaction with a link. We can provide any number of resources within a link but we only traverse between two at a time.

ARC: arc defines the link that we are traversing. Arc is a information that let us know that how we are travelling from one source to our destination and how the software will interact with the link as it is being traversed.

Behaviour: A software that is viewing our XML document governs the behaviour of a link.

The XLink Attributes Xlink uses a variety of attributes to create links that are embedded within our existing XML elements. These attributes are used to create one of the two different types of links offered by the XLink specification. XLink offers two kinds of links:

Extended links: Extended links offer full XLink functionality, such as inbound and third-party arcs, as well as links that have arbitrary numbers of participating resources. As a result, their structure can be fairly complex, including elements for pointing to remote resources, elements for containing local resources, elements for specifying arc traversal rules, and elements for specifying human-readable resource and arc titles.

Simple links: Simple links offer shorthand syntax for a common kind of link, an outbound link with exactly two participating resources. Because simple links offer less functionality than extended links, they have no special internal structure.

While simple links are conceptually a subset of extended links, they are syntactically different. For example, to convert a simple link into an extended

Web Technology

Unit 5

link, several structural changes would be needed. As we will see in the following discussion about XLink attributes.

The type attribute This is a primary attribute of XLink. This attribute provides the foundation upon which all other attribute values are interpreted and defines the type of link element being created. The type attribute has seven available values:

Simple

Extended

Arc

Title

Locator

Resource

none

Each of these types of links works with the other XLink attributes to create and define the XML link element we are creating.

The href attribute Href attribute supplies the URL of the destination resource of the links, just as it does in HTML links. The URL specified in this attribute can be either a relative or absolute address referencing either a remote or local resource. If the value of href is empty (“”) then it is assumed to reference the resource that the href element currently exists within.

Example <!AttList contact Xlink :type (simple)

#required

Xlink :href

CDATA

#Implied

>

The role, arcrole and title attributes These attributes are used to define the meaning of various resources that are part of the linking process. Both the role and arcrole attributes contain URI values the reference a resource that can be used to describe the sources associated in the link. The title attribute simply describes the link resource in terms that are readable by human beings.

The following sample provides a look at the DTD statements used to add the XLink role and title attributes to a simple linking element.

Web Technology

Unit 5

Example

<!AttList contact

Xlink : type (simple)

#required

Xlink : href

CDATA

#Implied

Xlink : role

CDATA

#Implied

Xlink : title

CDATA

#Implied

>

The arcrole attribute is used primarily with the arc type link.the following example creates the DTD statements that create an arc link in our XML document.

<!AttList contact

Xlink : type (arc)

#required

Xlink : href

CDATA

#Implied

Xlink : arcrole

CDATA

#Implied

Xlink : title

CDATA

#Implied

>

The show and actuate attributes The show and actuate attributes control the behaviour of our links. These attributes are only used with the simple and arc elements. when they are used with the simple link, they control the behaviour associated with the traversal of the link to its destination. when they are used with the arc element, they control the behaviour associated with whichever local or remote ending resource. The show attribute is in charge of identifying where the destination resource should appear. The show attribute can have the following values:

New: This value loads the destination resource in a new window, frame, pane, or other presentation area.

Replace: This value loads the resource in the source resource’s window, frame, pane, or other presentation area.

Embed: This value loads the ending resource in place of the source resource, such as what happens with an image loading in place of an <img> HTML element.

Web Technology

Unit 5

Self Assessment Questions

6. uses a variety of attributes to create links that are embedded within our existing XML elements.

7. attribute supplies the URL of the destination resource of the links, just as it does in HTML links.

a) Href

b) Type

c) Role

d) show

8. Which is a primary attribute of XLink?

5.5 XPointer

XML XPointer is a system for addressing components of XML based internet media. It can address locations that XPath cannot. Examples: points and range. Its specification uses a language derived from XPath to point to locations. Unlike XPath, XPointer can be used as a part of an URL. XPointer is divided among four specifications:

"framework" which forms the basis for identifying XML fragments,

a positional element addressing scheme,

a scheme for namespaces,

and a scheme for XPath-based addressing.

A positional element addressing scheme Positional element addressing scheme (Location paths) are built from location steps. Each location step specifies a point in the targeted document, always relative to some other well-known point such as the start of the document or the previous location step. This well-known point is called the context node. In general, a location step has three parts: the axis, the node test, and an optional predicate. These are combined in this form:

axis::node-test[predicate]

For example, in the location step child::PERSON[position()=2], the axis is child, the node-test is PERSON, and the predicate is [position()=2]. This location step selects the second person element along the child axis, starting from the context node or, less formally, the second PERSON child element of the context node. Of course, which element this actually is depends on what the context node is. Consequently, this is what's referred

Web Technology

Unit 5

to as a relative location step. There are also absolute location steps that do not depend on the context node.

The axis tells us in what direction to search from the context node. For instance, an axis can say to look at things that follow the context node, things that precede the context node, things that are children of the context node, things that are attributes of the context node, and so forth.

Namespace An XML Namespace is a concept. It is a named collection of names. It is not

a DTD reference, nor a pointer to an XML schema. A namespace does not even need to exist as a physical or network resource.

An XML Namespace is simply a group of names, usually with a related purpose or context, where the group has a globally unique name (the "namespace name"). This is often ensured by using a domain as the first part of the namespace name.

Unfortunately, numerous myths have arisen about XML Namespaces. Some myths are due to the differences between XML Namespaces and the more widely-understood namespaces in the context of programming languages, others have resulted from misreading the W3C specification, and yet others reflect unsatisfied desires about shared DTDs and other deficiencies of XML 1.0 syntax and processing. Even the statements at the beginning of this section could be misleading if the reader insists on assuming that a "group of names" implies a tangible list.

It is important to understand that XML Namespaces are not:

Resources that exist anywhere (other than conceptually).

A part of XML 1.0 syntax.

Directly related to DTDs or XML Schemas.

A redefinition of XML data validity.

Something with any semantic meaning.

An object, an interface, or something with a specific internal structure.

Scheme for XPath-based addressing XPath is the result of an effort to provide a common syntax and semantics for functionality shared between XSL Transformations (XSLT) (already discussed in unit 4) and XPointer. The primary purpose of XPath is to address parts of an XML [XML] document. In support of this primary

Web Technology

Unit 5

purpose, it also provides basic facilities for manipulation of strings, numbers and Booleans. XPath uses a compact, non-XML syntax to facilitate use of XPath within URIs and XML attribute values. XPath operates on the abstract, logical structure of an XML document, rather than its surface syntax. XPath gets its name from its use of a path notation as in URLs for navigating through the hierarchical structure of an XML document.

Self Assessment Questions

9. An XML

is a concept; it is a named collection of names.

is the result of an effort to provide a common syntax and semantics for functionality shared between XSLT and XPointer.

5.6 Event-driven Programming

In computer programming, event-driven programming or event-based programming is a programming paradigm in which the flow of the program is determined by events i.e., sensor outputs or user actions (mouse clicks, key presses) or messages from other programs or threads.

Event-driven programming can also be defined as an application architecture technique in which the application has a main loop which is clearly divided down to two sections: the first is event selection (or event dispatcher), and the second is event handling. In embedded systems the same may be achieved using interrupts instead of a constantly running main

loop; in that case the former portion of the architecture resides completely in hardware. Basically there three types of patterns in event-driven programming.

1. The Handlers Design Pattern

2. The Headless Handlers Pattern

3. The Extended Handlers Pattern

The Handlers Design Pattern Figure 5.2 s showing the handler pattern of events.

Web Technology

Unit 5

Web Technology Unit 5 Figure 5.2: Handlers Pattern of Events Above figure 5.2 is showing •

Figure 5.2: Handlers Pattern of Events

Above figure 5.2 is showing

A stream of data items

A dispatcher

A set of handlers.

The job of the dispatcher is to take each event that comes to it, analyze the event to determine its event type, and then send each event to a handler that can handle events of that type. The dispatcher must process a stream of input events, so its logic must include an event loop so that it can get an event, dispatch it, and then loop back to obtain and process the next event in the input stream.

In most of the event-handling applications the event stream is finite, with an end indicated by some special event an end-of-file marker, or a press of the ESCAPE key, or a left-click on a CLOSE button in a GUI. In those applications, the dispatcher logic must include a quit capability to break out of the event loop when the end-of-event-stream event is detected.

The Headless Handlers Pattern In this pattern, the dispatcher is either missing or not readily visible. Taking away the dispatcher, all that remains is a collection of event handlers. In this type of patterns there is no dispatcher only handlers are there to handle the event. Figure 5.3 shows headless handler patterns of events.

event. Figure 5.3 shows headless handler patterns of events. Figure 5.3: Headless Handler Patterns of Events

Figure 5.3: Headless Handler Patterns of Events

Web Technology

Unit 5

The Extended Handlers Pattern Another variant is the Extended Handlers pattern. In this variant, the pattern includes an events generator component that generates the stream of events that the dispatcher processes. In this type of pattern first of all event generator will generate the event and send it to the dispatcher to dispatch the event to the handler. Figure 5.4 is showing the extended handlers pattern of events.

5.4 is showing the extended handlers pattern of events. Figure 5.4: Extended Handlers Pattern of Events

Figure 5.4: Extended Handlers Pattern of Events

Advantages of event driven programming

It allows for more interactive programs. Almost all modern GUI programs use event driven programming.

It can be implemented using hardware interrupts, which will reduce the power used by the computer.

It allows sensors and other hardware to easily interact with software.

Flexible: It allows the programmer to visually design the form to their needs and program the objects on the form with a huge range of sevents that can do different things when run.

Suitability for graphical interfaces: Because of the graphical way a programmer creates their program in an event driven programming language it is much suited to graphical user interfaces. When programming with an event driven language, the programmer can select different controls such as a command button and place it on the form where necessary.

Web Technology

Unit 5

Ease of development: Developing a program in an event driven language is easy because of the way the programmer only has to deal with event of one control at a time.

Simplicity of programming: The visual aspect of event driven programming simplifies even the most complex programming tasks. Because the programmer can visually create their program by placing different objects on the form, it saves a lot of time and effort.

Self Assessment Questions

11.

includes an events generator component that

 

generates the stream of events that the dispatcher processes.

12.

The

must process a stream of input events.

5.7 XML Scripting

The former (XML Script) is an XML transformation language. XSLT stands for "Extensible Stylesheet Language: Transformations", it is a programming language designed specifically to transform an input XML document into an output XML document which satisfies some specific goal. It is part one of a pair of standards that, together, are named XSL (Extensible Stylesheet Language). The second part of XSL, XSLFO -- "Extensible Stylesheet Language: Formatting Objects

Transformations in XSLT We have already mentioned that the "T" in XSLT represents the word "transformation". XSLT, then, provides a language to describe a transformation that can be applied to a set of (input) XML documents to generate a new set of transformed outputted documents. When one uses XSLT one, it has two XML DTD's in mind the DTD that describes the source document, and the DTD that describes the output document. One writes an XSLT document to describe how an XSLT processor should transform the text and markup in the source document into the desired output format. The process is shown diagrammatically in figure 5.4:

Web Technology

Unit 5

Web Technology Unit 5 Figure 5.4: Transformations Process in XSLT In the figure 5.4 the original

Figure 5.4: Transformations Process in XSLT

In the figure 5.4 the original XML document on the left, an XSLT transformation specification (given in what is called an XSLT Transformation Stylesheet document) at the bottom, and the resultant XML document being generated by the XSLT transformation processor shown on the right. Note that HTML is shown above as a possible kind of output from an XSLT processor. Now we probably already know that traditional HTML is not an XML markup language, since it doesn't require the various rules that apply to XML markup.

A sample Transformation Example Here is an example of a simple transformation (into HTML!) of the kind that XSLT handles

an example of a simple transformation (into HTML!) of the kind that XSLT handles Sikkim Manipal

Web Technology

Unit 5

The XML document is shown on the left, the transformed HTML document on the right. We might already have noticed that the XML document is shown without specifying a DTD, but that it follows all the basic rules of XML (that all opening tags must be matched with closing tags, that tags must be properly nested, etc.). XML documents that follow these rules even if they do not have a DTD, are called well-formed. All that an XSLT processor requires of an XML document is that it be well-formed. A DTD is not needed, and for most of our examples in this course you will find that a DTD has not been provided.

Several things should be noted about this XSLT transformation document:

It is, itself, a well-formed XML document using elements, attributes and element contents to describe the transformation.

It contains elements from two different tag-sets (or, if we like, "DTDs") mingled together. Some of the elements (such as <html> or <h3>) are elements defined in HTML itself. whereas some of them are defined in the XSLT specification. All the XSLT-defined elements shown here begin xsl.

The basic structure of this simple stylesheet, after the initial startup tag, and the XSLT xsl:output element, is a series of rules written formally which essentially say what we informally said were needed to do the transformation above. The rules are called templates in XSLT parlance. Each template element defines the form of some part of the output document that is to be generated whenever the input document's structure matches the given pattern. For example, the first template element begins "<xsl:template match="title">", and this element start tag, with its match attribute, should be read as saying "I contain a definition of what is to be generated in the output document whenever the XSLT processor finds a 'title' element."

There are a number of different ways to specify what should appear in the output document when a particular template matches the material in an input XML document. Here, the contents of each template element are mainly a set of HTML elements.

Inside each template element in our example is one occurrence of another XSLT element -- the empty <xsl:apply-templates/> element. The apply-templates element marks the place where the contents of the template's input element (after it is suitably transformed by other

Web Technology

Unit 5

template element specifications, if any) should be inserted. In effect, then, in this stylesheet, the xsl:apply-templates/ element marks the division between the material that is to appear in the output document before the input element's content, and after it.

For example, look at the template for the "title" element:

<xsl:template match="title"> <h3 align="center"><xsl:apply-templates/></h3> <hr/> </xsl:template>

and compare this with the XML input and HTML output shown earlier. The HTML tags for the h3 element surround the xsl:apply-templates element in the template, since the contents of the XML title tag is meant to be surrounded by the H3 when the HTML is generated. The HTML hr tag follows the closing h3 tag since that is where we want it in the HTML output.

Note that in the xsl: template shown above, the HTML tag, usually written in a conventional HTML document as <hr>, is shown here as an XML empty tag: <hr/>. This is because it is appearing in the middle of an XSLT stylesheet, which is, an XML document.

Note as well that the ordering of the template elements in the XSLT is not significant an XSLT processor would produce exactly the same result if the stylesheet contained the template element for quote elements first rather than last. Each rule is described independently of any other rule. With this XSLT transformation stylesheet, the ordering of the output HTML document is determined not by the ordering of the templates in the XSLT file, but instead entirely by the ordering of the elements in the input XML document.

5.8 Summary

In this unit we have explained about XML object that is used to eliminate the distinction between the string representation and the object representation of XML documents.

Then we learnt about how to check the validity of a document, how we can link a XML document to DTD etc.

Web Technology

Unit 5

We have discussed about XLink concept and its various attributes and XPointer concepts also.

In this unit we have learnt about event driven programming and its 3 type of handling patterns.

At last in XML scripting we have learnt about transformation of XML document. An XML transformation language is a programming language designed specifically to transform an input XML document into an output XML document which satisfies some specific goal.

5.9 Terminal Questions

1. Define various features of XML objects.

2. How we can link a XML document with DTD?

3. Define various attributes of Xlink.

4. Explain about XPointer in detail.

5. How can we transform a XML program in to HTML program?

5.10 Answers

Self Assessment Questions

1.

Dot(.)

2.

True

3.

Public

4.

Well formed

5.

True

6.

XLink

7.

Href

8.

Type

9.

Namespace

10.

Xpath

11.

Extended Handlers Patterns

12.

Dispatcher

Terminal Questions

1. XMLObject supports different adapters to do the actual XML parsing. It

ships with REXML (supports both tree and stream document parsing.), and LibXML adapters. By default, the REXML adapter is used. For more details refers section 5.2.

Web Technology

Unit 5

2. Now that we've created a DTD for an XML document, we need to link the XML to the DTD. This takes place in prolong of the XML document. For more details refers section 5.3.

3. Xlink uses a variety of attributes to create links that are embedded within our existing XML elements. These attributes are used to create one of the two different types of links offered by the XLink specification. XLink offers two kinds of links: For more details refers section 5.4.

4. XML XPointer is a system for addressing components of XML based internet media. it can address locations that XPath cannot. Examples:

points and range. Its specification uses a language derived from XPath to point to locations. For more details refers section 5.5.

5. Here is an example of a simple transformation (into HTML!) of the kind that XSLT handles. For more details refers section 5.8

E-References:

http://eventdrivenpgm.sourceforge.net/11/10/20211.

http://www.dbase.com/help/Intro_to_Prg/IDH_PROG_EVENT_DRIVEN.

htm12/10/2011.

http://computersight.com/computers/uses-and-advantages-of-event-

driven-programming/