Web Engineering Stud

WEB ENGINEERING
Prepared by :Priyanka Desai Page

1 12/23/2010
Web Engineering and Software Engineering
Though Web engineering involves some programming and software
development, and adopts some of the principles of the software
engineering, Web-based system development is different from
software development, and also Web engineering is different from
software engineering.
1. Most Web-based systems, at least as of now, are document-oriented
containing static or dynamic Web pages.
2. Web-based systems will continue to be focussed on look and feel,
favouring visual creativity and incorporation of multimedia (in varying
degrees) in presentation and interface. More emphasis will be placed
on visual creativity and presentation as regards to the front-end
interface with which a user interacts.
3. Most Web-based systems will continue to be content-driven – often
Web-based systems development include development of the content
presented.
4. Multiplicity of user profiles – Most Web-based systems need to cater
to users with diverse skills and capability, complicating human-
computer interaction, user interface and information presentation.
5. The nature and characteristics of the medium of Web is not well
understood as the software medium.
6. The Web exemplifies a greater bond between art and science than
generally encountered in software development.
7. Most Web-based systems need to be developed within a short time,
making it difficult to apply the same level of formal planning and
testing as used in software development.
8. Also Web is different from software as related to the delivery
medium.
9. Further, the type of individuals who build/develop Web-based
systems are vastly varied in their background, skills, knowledge and
system understanding, and as well as their perception of Web and
quality Web-based system.
CHAP 1 AN INTRODUCTION TO WEB ENGINEERING
Notations
HTML:HYPER TEXT MARKUP LANGUAGE
RE:REQUIREMENTE ENGINEERING
Background of web engineering

To introduce relevant formal language specifications for describing
semantic information of Web services and software components
• To support semantic description for the complete life-cycle
• To introduce understandable and processable semantics:
Ontologies,Ontology Languages, Ontology merging and alignment,
Ontology Reasoning
• To provide the proper way for automation of composition,
mediation,compensation, execution of software components and Web
services
• To introduce variability and probability features into the semantic
description process (diversity of user groups, business
scenarios,environment)
• To distinguish different levels of semantic formalisms and define
relevant formal logical specifications for them
Why do we need Web Engineering?

INTRODUCTION
What is Web Engineering?

• “The application of systematic and quantifiable approaches to cost-
effective analysis, design, implementation, testing, operation, and
maintenance of high-quality Web applications.” –
Kappel
• Extends Software Engineering to Web applications, but with Web-
centric approaches.
– And other relevant contributions from many disciplines
MOTIVATION OF WEB APPLICATION

• work with and
• depend on a concrete _SYNTACTIC_ representation of the information
• To acquire information from different sources and domains is a
difficult task
• Web service standard specifications do not support dynamic
composition
• Until now, “semantic” description approaches do not cover full
business life-cycle
1.1 Motivation
Defining Web Applications
• Unlike traditional software, the Web serves as both development &
user platform.
• A Web application is a system that utilizes W3C standards &
technologies to deliver Web-specific resources to clients (typically)
through a browser.
– Kind of …
• Technology + interaction.
– Web site with no software components?
– Web services?
The strong interlinking of web applications additionally increases the
danger of problems spreading from one application to other. The
reasons for this situation are complex:
• Document centric approach: The development of web
applications is often still considered to be document centric
i.e.,an authoring activity that includes the creation and linking of
web sites and the inclusion of graphics.Applications such as(e.g.
homepage ,online news paper etc)fall in this category,such
viewpoint is not adequate for the development of software
intensive web applications.
• The assumed simplicity of web applications development:
Availability of HTML editors makes application simple .Usually the
emphasis is on visual design rather than internal structuring and
programming. This results in inconsistencies and redundancy.
• Know-how from relevant disciplines cannot be applied or is not
used: It is common misconception that the development of web
applications is analogus to the development of traditional
applications and that therefore the methods of software
engineering can be used in the sense of a systematic disciplined
approach with adequate quality control measures.
Software engineering is defined as the application of science and

mathematics by which the capabilities of computer equipment are
made useful to man via computer programs,procedures,and associated
documents.
Web engineering is as follows:
• Web engineering is the application of systematic and quantifiable
approaches(concepts,methods,techniques,tools)to cost-effective
requirements analysis
,design,implementation,testing,operation,and maintenance of
high –quality web applications.
• Web engineering is also the scientific discipline concerned with
the study of these approaches.
Web Engineering (703512) 14
The Case for Web Engineering
• Application development on the Web remains largely ad hoc.
– Spontaneous, one-time events
– Individual experience
– Little or no documentation for code/design
• Short-term savings lead to long-term problems in operation,
maintenance, usability, etc.
• Because Web apps are so interdependent, the problem is
compounded.eb Engineering (703512) 15
• Root Causes of poor design
– Development as an authoring activity
– Development is “easy”
– Techniques that should not be used are misapplied.
– Techniques that should be used are not.
• Particularly alarming given…
– Most projects are now Web-based
– More “mission-critical” apps moving to the Web
• Top project pitfalls (Cutter, 2000)
– 84% - Failure to meet business objectives
– 79% - Project schedule delays
– 63% - Budget get overrun
– 53% - Lack of functionality
• Web Engineering’s solution:
– Clearly defined goals & objectives
– Systematic, phased development
– Careful planning
– Iterative & continuous auditing of the entire process
• Web Technologies pose new restriction to software development
– HTTP
– URL
– HTML
• HTTP is stateless
– unless you use tricks
• Web is based on the pull mechanism
– unless you this? Tricks are not good!
– It’s a trade off…
We can infer from above the basic principles of Web engineering are
similar to those of software engineering(Lowe 1999,Selmi 2005)
• Clearly defined goals and requirement
• Systematic development of a web application in phases
• Careful planning of these phases
• Continuous audit of the entire development process.
1.2 Categories of Web Applications

Web applications have varying degrees of complexity.They may be
purely informational or handle full-size /full-fleged 24/7 e-commerce
applications.Fig identifies different categories of web applications
depending on their development history and their degree of
complexity and gives example.
Document-Centric Web sites
• Precursors to Web applications
• Static HTML documents
• Manual updates
• Pros
– Simple, stable, short response times
• Cons
– High management costs for frequent updates & large
collections
– More prone to inconsistent/redundant info
Interactive & Transactional

• The Common Gateway Interface
– http://hoohoo.ncsa.uiuc.edu/cgi/interface.html
• Simple interactivity
• Dynamic page creation
• Content updates -> Transactions
– Decentralized
– Database connectivity
– Increased complexity
Workflow-Based Applications
• Designed to handle business processes across departments,
organizations & enterprises
• Business logic defines the structure
• The role of Web services
– Interoperability
– Loosely-coupled
– Standards-based
• Examples: B2B & e-Government
• High complexity; autonomous entities
Collaborative & Social Web

• Unstructured, cooperative environments
• Interpersonal communication is paramount
• Classic example: Wikis
• The Social Web
– Anonymity traditionally characterized WWW
– Moving towards communities of interest
– Examples: Blogs, collaborative filtering systems, social bookmarking
(e.g., del.icio.us)
– Integration with other forms of web applications (e..g, NetFlix)
Portal-Oriented
• Single points-of-entry to heterogeneous information
– Yahoo!, AOL.com, my.pitt.edu
• Specialized portals
– e g Business portals (e.g., employee intranet)
– Marketplace portals (horizontal & vertical)
– Community portals (targeted groups)
Ubiquitous
• Customized services delivered anywhere via multiple devices
• HCI is critical
– Limitations of devices (screen size, bandwidth?)
– Context of use
• Still an emerging field; most devices have single focus:
– Personalization
– Location-aware
– Multi-platform delivery
Semantic Web
• Berners-Lee: Information on the Web should be readable to
machines, as well as humans.
• Using metadata and ontologies to facilitate knowledge management
across the WWW.
• Content syndication (RSS, Atom) promotes re-use of knowledge
• Is the Semantic Web even possible?
• Authors devote a chapter to the Semantic Web, but we will not focus
on it in this course.
1.3 Characteristics of Web Apps
• How do Web applications differ from traditional applications?
• Or, another way, what Software Engineering methods & techniques
can be adapted to Web Engineering?
• 3 dimensions of the ISO/IEC 9126-1 standard
– Product
– Usage
– Development
• To this we can add a 4th dimension peculiar on the web, need for
continuous and fast evolution!
Flowchart of Characteristics of Web Applications
USE
Technical
contextContext Physic
Social al
Contex contex
t PRODUCT t
Presentation Contex
Hypertext t
Project Content
Integratio
team nnnnnn
Team
Technical
infractureInfrastruct
ure
DEVELOPMENT
Characteristics - Product
• The “building blocks” of a Web application
• Content
– Document character & multimedia (# of dimensions?)
– Quality demands
• Navigation Structure (Hypertext)
– Non-linearity
Social
Context
– Disorientation & cognitive overload
• User interface (Presentation)
– Aesthetics
Developmen
Team
Develop
Proc
– Self-explanation
Characteristics - Usage
• Much greater diversity compared to traditional non-Web applications
• Social Context (Users)
– Spontaneity
– Heterogeneous groups
• Technical Context (Network & Devices)
– Quality-of-Service
– Multi-platform delivery
• Natural Context (Place & Time)
– Globality
– Availability
eb Engineering (703512)
Characteristics - Development
• The Development Team
– Multidisciplinary
– Community (including Open Source)
• Technical Infrastructure
– Lack of control on the client side
– Immaturity
• Process
– Flexibility
– Parallelism
• Integration
– Internal
– External
The 4th Dimension: Evolution

• All the above mentioned dimension are governed by the evolution
principle
– Continuous change
– Competitive pressure
– Fast pace
• Software Engineering: evolution is planned in a constant number of
release version
• Web Engineering: evolution is continuous
– Nowadays this is becoming true also for SE… it’s a loop, when a
discipline overlaps its ancestor, the ancestor learn something back!
Key Knowledge Areas

Standardization
– Standards are important, especially for national initiatives and other

large-scale services
• More easy to integrate different projects if they adopt standards
– Proprietary solutions are often tempting because:
• They are available
• They are often well-marketed and well-supported
• They may become standardized
• Solutions based on standards may not be properly supported by
applications
Things to keep in mind
(or summary)
• Web Engineering is not about HTML and JavaScript
– Like Software Engineering is not about C or Java!
• It aims at systematic development of Web
applications according to a specific methodology
• Web Engineering is not just Software Engineering
for the Web
• Web Engineering ask for multidisciplinary approach
• Standards are important in Web like in all the other
Engineering fields
Mandatory reading(learning)
– Web Engineering(Kappel)
• Chapter 1
Self learning
• Suggggested
– Google “Web Engineering”
– (link to localization http://www.w3.org/2006/07/MWI-EC/Presentation/cdac.ppt)
CHAP 2 REQUIREMENT ENGINEERING OF WEB APPLICATION
Notations
RE:REQUIREMENTS ENGINEERING
Background
When the “Software Crisis”1 was discovered and named in the 1960s,
much effort was directed at finding the causes of the now-familiar
syndrome of problems. The investigations determined that
requirements deficiencies are among the most important contributors
to the problem: “In nearly every software project which fails to meet
performance and cost goals, requirements inadequacies play a major
and expensive role in project failure.” 2 Development of the
requirements specification “in many cases seems trivial, but it is
probably the part of the process which leads to more failures than any
other.” It was determined that the benefits of good requirements
include:
· Agreement among developers, customers, and users on the job to be
done and the acceptance criteria for the delivered system
· A sound basis for resource estimation (cost, personnel quantity and
skills, equipment, and time)
· Improved system usability, maintainability, and other quality
attributes
· The achievement of goals with minimum resources (less rework,
fewer omissions and misunderstandings)
Iteration in partitioning, allocation, and flowdown
The process of partitioning, allocation, and flowdown is then repeated to as low a level as
needed for this particular system; for software elements this is often to the module level.
Figure 9 emphasizes the iterative nature of this process at each level in the many levels of
partitioning, allocation, and flowdown.
Overview
• Introduction to Requirements Engineering
– Principles
– Adapting traditional Requirements Engineering to Web applications
– Specifics in Web Engineering
• Elicitation & Negotiation
• Specification
• Validation and Management
• Example
Why do we need Web Engineering?
2.1 INTRODUCTION
Requirements play a key role in the development of web
applications.However ,requirements are often not described properly
and may be specific in an ambiguous ,vague, or incorrect manner.
Typical consequences of poor requirement are low user acceptance ,
planning failures ,or inadequate software architectures.
• Requirements Engineering (RE) – the principles, methods & tools for
eliciting methods, eliciting, describing, validating, and managing
project goals and needs.
• Given the complexity of Web apps, RE is a critical initial stage, but
often poorly executed.
• What are the consequences?
– Inadequate software architectures
– “Unforeseen” problems
• Budget overruns
• Production delays
• “That’s not what I asked for”
– Low user acceptance
What is a Requirement?
• A requirement describes a property to be met or a service to be
provided by a system.
• IEEE 601.12 definition of requirement:
1. Condition needed to solve a user’s problem
2. Condition to be met or possessed by the system to satisfy a formal
agreement
3. Documented representation of conditions as in 1 and 2
• Key players in the game
– Contract
– Customer
– Supplier
- User
Why do we need Requirements?

• Bell & Thayer (1976) – Requirements don’t define themselves.
• Boehm (1981) – Removal of mistakes post hoc is up to 200 times
more costly than early identification and correction.
• The software industry is still struggling with massive difficulties when
it comes to requirements:
–1995 study in 340 companies in Austria showed,2/3rd of companies
regarded development of requirements documentation as a major
problem in addition ½ said requirements management as a major
problem
– The Standish Group (1994) – 30% of projects fail before completion &
almost 70% do not meet customer requirements. More than half had a
problem of unclear objectives, unrealistic schedules & expectations,
poor user participation
–According to Cutter Consortium 16% of the systems fully meet the
requirements of contractors, while 53% of the deployed systems do not
satisfy the required capabilities
Good Requirements Specifications

• Correct
– Correspond to actual need
• Unambiguous
– Can be interpreted only in one way
• Complete
– Any external imposed requirement should be included
• Consistent
– Conflicting requirements should be avoided
• Ranked for importance and/or stability
– Requirements are not equally important
– Requirements are not equally stable
• Verifiable
– It’s possible to use a cost-effective process to check it
• Modifiable
– Can be restructured quickly
– Adopt cross reference
– Requirements are clearly separated
• Traceable
– Can be tracked from originating design documentation
Types of Requirements
• Many taxonomies exist to describe requirements, but most divide
them into two groups:
– Functional – describes the capability’s purpose
• e.g., the ability to transfer money between user accounts
– Non-functional – describes the capability’s properties
• e.g., the Home Page must load within 5 seconds on a dial-up
connection
Functional Requirement Types

• Data Requirements
– How information is stored and managed
• Interface Requirements
– How the user is going to interact with the application
• Navigational Requirements
– How the user is going to navigate through the application
• Personalization Requirements
– How the application adapt itself according to user or environment
profile
• Transactional Requirements
– How the application behave internally
Non-Functional Requirement Types

• Content
• Quality
– Functionality, Usability, Portability, Scalability
– Reliability Efficiency Security Reliability, Efficiency, Security,
Maintainability
• System Environment
• User Interface
• Self-explanatory & intuitive
• Usage-centered design
• Evolution
• Project Constraints
2.2 Fundamentals
• Where do requirements come from
• Requirements engineering activities
• Requirements elicitation and negotiation
• Requirements documentation
• Requirements verification and validation
• Requirements management
2.3 Specifics in Web Engineering

• Is RE for the Web really that different than RE for conventional
software?
• Top 6 distinguishing characteristics
– 1) Multidisciplinary teams: The development of web applications
requires the participation of experts from different disciplines. Eg.
Multimedia experts ,content experts ,software architects ,usability
experts , database specialists ,or domain experts.
– 2) Unavailability of stakeholders: Many stakeholders ,such as
potential web users , are still unknown during RE activities. Project
management needs to find suitable representatives that can provide
realistic requirements. Eg. There is a wide spectrum of possible users
in web projects and finding a reasonable set of representatives is hard.
– 3) Rapidly changing(Volatility) requirements & constraints: Web
applications and their environments are highly dynamic and
requirements and constraints are typically harder to stabilize. Frequent
examples of changes are technology innovations such as the
introduction of new development platforms and standards ,or new
devices for end users.
– 4) Unpredictable operational environment:Developers find it hard or
impossible to control important factors that are decisive for the user
perceived quality of a web application.Eg. changing bandwidths afftect
the response time of mobile applications but are outside the sphere of
the development team(Finkelstein and Savigni 2001)
– 5)Impact of legacy systems: Web applications is characterized by the
integration of existiong software components such as commercial off-
the-shelf products or open source software.In particular ,web
developers frequently face the challenge to integrate legacy systems,
for example when making existing IT systems of a company accessible
through the Web.Developers are often asked to use existing
components for economic reasons.Waterfall model will not
succeed.This means that ,when identifying and defining
requirements ,Web developers have to be aware of the system
architecture andarchitectural constraints.
– 5) No manual for the user interface
– 6) Content Management
2.4 Principles for RE of Web applications

Web developers should keep the following principles in mind when
performing RE activities:
• Understanding the system context
– Web apps are always a component of a larger entity
– Why do we need the system?
– How will people use it?
• Involving the stakeholders
– Get all groups involved.
– Balance – one group’s gain should not come at the expense of
another.
– Repeat the process of identifying, understanding and negotiating.
• Iteratively define requirements
– Requirements need to be consistent with other system aspects (UI,
content, test cases)
– Start with key requirements at a high level; these will serve as the
basis for:
• Feasible architectures
• Key system use cases
• Initial plans for the project
– As the project progresses, requirements can become more concrete.
• Focusing on the System Architecture
– The “solution space” – existing technologies & legacy systems –
defines the “problem space.”
– The architecture must be considered in the elicitation stage.
– Refine requirements and architecture iteratively with increasing level
of detail.
• Risk Orientation
– Risk management is at the heart of the analysis process.
– What are the typical risks?
• Integration issues w/ legacy systems
• Expected vs. actual system quality
• Inexperience of developers
– How to mitigate risks?
• Prototyping (avoid IKIWISI)
• Show changes to customer iteratively
• Integrate existing systems sooner than later
2.5 Adapting RE to Web Application Development

• There isn’t one single “right way” to do RE among the many
methods, techniques, tools, etc. available.
• For your Web application project, ask the following questions:
– What are the critical requirements?
– How should requirements be documented?
– What tools should be used, if any?
The Requirements Collection
Process
How to interact with Stakeholders

ELICITATION & NEGOTIATION
• Identify and involve (if possible) the stakeholders
– Those that directly influence the requirements
– Customers, users, developers
• What are their expectations?
– May be misaligned or in conflict.
– May be too narrowly focused or unrealistic.
• Why is the web application being developed in the first place?
Techniques for Elicitation & Negotiation

• Interviewing
• Joint Application Design
• Brainstorming
•Concept Mapping
• Storyboard
• Use Case Modeling
• Questionnaires
• Terminology Comparison
Challenges with Stakeholders

• McConnell (1996)
– Users don’t know what they want.
– Lack of commitment.
– Ever-expanding p g requirements.
– Communication delays.
– Users don’t take part in reviews.
– Users don’t understand the technology.
– Users don’t understand the process.
Challenges with Developers

• Users and engineers/developers speak different “languages”.
• The tendency to “shoe-horn” the requirements into an existing model
– Saves time for developers, but results may not meet user’s needs.
• Engineers & developers are also asked to do RE, but sometimes lack
negotiating skills and domain knowledge.
How to “formalize” received inputs

SPECIFICATION
Specification – Traditional RE
• 4 main categories of notation
– Stories – Plain-language scenarios; understandable to non-technical
persons.
– Itemized Requirements – Plain-language lists of requirements
– Formatted Requirements – Accurately-defined, but allow for plain-
language descriptions
• Ex. Use case scenarios in UML
– Formal Specifications – Expressed in formal syntax & semantics;
rarely used in Web applications.
Specification – RE for Web Apps
• So, what’s best for a Web development project?
– Formatted requirements (i.e. use cases) and stories are heavily used.
– Low to medium accuracy is suitable for Web apps; formal
specifications very rarely required.
– Keep effort for eliciting and managing requirements low.
– Scalability is most likely) y ( y) important.
VALIDATION AND
MANAGEMENT
Validation
• This step is essential to verify that requirements specification
corresponds to user’s needs and customer’s requirements
• Iterative feedback from stakeholders is essential
– Is the requirement feasible?
– Do the results meet stakeholders’ expectations?
• We will discuss testing in greater detail later
Validation Techniques
• Review or walk-through
– Reading and correcting the requirements definition documentation
and models
• Audit
– Partial check of the results presented in the review documentation
• Traceability Matrix
– Comparison of the application objectives with the requirements of the
system
• Prototyping for Validation
– Implement a partial set of functional requirements but provide a
global vision of the user interface
Management
• Several tools are available to support Requirements
( management also Open Source)
– http://www.paper-review.com/tools/rms/read.php
• Tool support is crucial for big project
• Enable
– Traceability
– Modifiability
– Verifiability
EXAMPLE
Requirement analysis
• Revision and formalization of the collected requirements, producing
in output a set of semiformal specifications, typically in terms of:
I. Group specification
II. Use-case specification
III.Data dictionary specification
IV.Site view specification
V. Style guidelines specification
VI.Acceptance tests specification
I. Group specification
• Clustering of users into groups (formally described)

• Formal description of units of interaction with the application by
users of a given group (e.g., thru tables or UML diagrams)

2. Single use case specification (table or activity diagram)
III. Data dictionary specification
• List of the main information objects identified during data
requirements collection
• Each entry can be specified by:
– Name
– Synonyms
–Description
– Sample instances
–Properties
–Relationships
–Components
–Super-concept
– Sub-concepts
IV. Site Map specification

• IN: list of user groups, list of use cases, data
dictionary
• OUT: list of needed site maps, specified by:
– Name
–Description
– Target User Groups
– Implemented use cases
– Site view map: a table illustrating the different areas that
compose the site view. Each area is specified by:
• Area Name
• Area Description
• Accessed/Managed Objects
• Priority level
Web E
) 38
Rules for the presentation of pages:
• Specification of standard page grids: rows, columns and cells
arrangement
• Content positioning specification: banners, logo, menus positioning
• Graphical guidelines: rules for graphic items like fonts, colors,
borders and margins
• Device-specific and browser-specific guidelines
• Example: Mock-ups: sample representations of a few typical
application pages for a specific device and rendition language)
W) 40

(or summary)
• Know your Audience & Objectives
– Balancing stakeholder interests
– Focus on high-level requirements first.
• Elicitation & Negotiation is a learning process
• RE requires flexibility
– Iterative changes should be expected
– Be sure stakeholders understand this!
• Clear documentation is critical
• Mandatory reading(learning)
– Web Engineering(Kappel)
• Chapter 2
– M.J. Escalona and N. Koch, Requirements Engineering for Web
Applications - A Comparative Study, JWE Vol.2, N. 3
• http://www.rintonpress.com/xjwe1/jwe-2-3/193-212.pdf
•Self Learning
• Suggggested
– IEEE Recommended Practice for Software Requirements
Specifications, IEEE Std 830-1998
Notations
W3C:WORLD WIDE WEB CONSRTIUM
HTTP:HYPERTEXT TRANSFER PROTOCOL
HTML:HYPERTEXT MARKUP LANGUAGE
Overview
• Introduction
• HTML & XHTML
• CSS
• JavaScript
Chap 3 Technologies for Web Applications
What are the basic ingredients to start to build a Web site
INTRODUCTION
Basic Ingredients
Content structuring (and “basic” presentation…)
– (X)HTML
• Business logic (client side)
– JavaScript
• Presentation
– CSS
• … with these 3 elements you can start building nice (content static)
interfaces for you web applications
Standards or not Standards?

XHTML and CSS are recommendation from W3C
XHTML 1 1 (2 0 i – 1.1 2.0 is currently a draft)
• http://www.w3.org/MarkUp/
– CSS 2.1 (3.0 is under development)
• http://www.w3.org/Style/CSS/
• JavaScript is “not” a standard
– This due to the fact also that at the beginning there was some
competition between Sun scripting language and Mircrosoft one
– An attempt of standardization was made by European Computer
Manufacturers Association (ECMA), never completed (last version dates
back to 1999)
– http://en.wikipedia.org/wiki/JavaScript
How to structure your content in a Web page
HYPERTEXT MARKUP LANGUAGE
HTML & XHTML
• W3C
– Set Standards
• Syntax
• Functionality
• HyperText Markup Language (v4.01 – 1999)
– Type of More General Language (SGML)
– Describes Function of Text Using Codes
• Extensible HTML (v2.0 – 2004)
– Stricter Version of HTML
– Integrate HTML with XML
• HTML Advantages
– Platform Portability
– Speed (size of file)
– Text File
HTML Disadvantages
– Rendering Differences
– Extensions
• Proprietary Functionality Added by Browsers
XHTML Advantages
– Resolve Issues with Different HTML Versions
Syntax
• Elements (Tags)
– Codes that Control Content Appearance
– Opening/Closing
• Two-Sided
– <tagName>Content</tagName>
• One-Sided
– <tagName />
– Lowercase
• Deprecated
– Obsolete Elements or Syntax
– Future Support Not Guaranteed
• Comments
– 
• 
• White Space
– Does Not Render Multiple Spaces
– Tab, Enter do not Render
– Use Non-breaking Space
•
• Attributes
– Controls Behavior or Appearance of Element
• <tagName attrib#1=“Value” attrib#2=“Value” />
<html>
• <html>…</html>
– Surround All Markup & Text
– Required
– Used To Begin & End Every g y HTML Document
<head>
• <head>…</head>
– Contains the Document's Header Information
– Required
– Important Information
• Document Title
• META Tags
– Text Included Does Not Render
<body>
• <body>…</body>
– Contains All Content to be Rendered
• Attributes
– leftmargin=number
• Sets The Left Margin for Page
– topmargin=number
• Sets the Top Margin for the Page
• Styles
– style=“color: colorName | #rrggbb | rgb(#,#,#);”
• Specifies the Color of the Regular Text
– style=“background-color: colorName | #rrggbb | rgb(#,#,#);”
• Specifies the Background Color
– style=“background-image: url(filename.ext);”
• Points to Location of Image that is Used as Background
• Image is Tiled
• Styles
– style=“background-position: horizontal vertical;”
• Specifies the Positioning of the Background Image
• Can Specify Keywords or Percentages
– style=“background-repeat: repeat | repeat-x | repeat-y | norepeat;”
• Specifies the Tiling of the Background Image
– style=“background-attachment: scroll | fixed;”
• Background Image Scrolls with Page or Acts as Watermark
<h#>
• <h#>…</h#>
– Create a Heading
– Numbered from h1 through h6
• h1 is the Top Head Level While h6 is the Bottom
– Should not be Used for Text Formatting
– Convey Page & Content Organization
– Should be Used in Descending Order
• Style
– style=“text-align: left | center | right | justify;”
• Specifies the Alignment of the Heading Text
<p> & <br>

• <p>…</p>
– Inserts Blank Line Before Tag
• Separates Paragraphs of Text
• <br />
– Causes Text To Break Wherever Tag is Placed
Lists
• <ul>…</ul>
– Unordered List Renders a Bulleted List
– Use Where Order or Rank is Unimportant
• Style
– style=“list-style-type: disc | square | circle;”
• Changes Style of Bullet Before Item
– style=“list-style-image: url(filename.ext);”
• Image Used as Bullet
• <ol>…</ol>
– Ordered List Tags Render a Numbered List
• Style
– style=“list-style-upper-upper-style list style type: decimal | upper
roman | upper alpha |
. . .;”
• Changes Number / Letter Style Before Item
– style=“list-style-position: inside | outside;”
• Changes Wrapped Item Placement
• <li>…</li>
– Defines an Item in a List
• <dl>…</dl>
– Definition List
– <dt>…</dt>
• Defined Term
– <dd>…</dd>
• Definition
Block Level Elements

• <blockquote>…</blockquote>
– Content Indented on Left & Right
• <pre>…</pre>
– Retains All White Space
– Uses Fixed Width Typeface
Inline Elements
• <strong>…</strong> or <b>…</b>
– Bold
• <em>…</em> or <i>…</i>
– Italics
• <sub>…</sub>
– Subscripted
• <sup>…</sup>
– Superscripted
• <span>…</span>
– Used for Applying CSS Classes
• Nesting
– Placing Sets of Tags Within Each Other
• <b><i>…</i></b> instead of <b><i>…</b></i>
<img>
• <img />
– Inserts an Image Into a Document
– Secondary to Content
• Attributes
– alt=“text”
• Provides Alternative Text that Describes the Image
• IE Displays ALT Text When User Hovers on Image
– Users Who Surf With Graphics Turned Off
– Non-graphical Browsers
» Alt Text is Displayed in Place of Image
• Required
• Attributes
– height=“pixels”
• Specifies the Image's Height
– src=“URL”
• Specifies Location of Image to Place in Web Page
• Required
– width=“pixels”
• Specifies the Image's Width
• Style
– style=“float: none | left | right;”
• Place Image on Left / Right & Wrap Text Around It
– style=“clear: none | left | right;”
• Display Content After Margin is Clear of Floating Elements
– style=“margin: top# right# bottom# left#;”
– style=“yle=“border-width: #;”
• Rendered in Designated Link Color if Image is a Link
<hr>
• <hr />
– Inserts Plain Line (Horizontal Rule) Across Page
– Emphasize Divisions & Transitions In Content
• Style
– style=“background-color: #RRGGBB | colorname;”
– style=“color: #RRGGBB | colorname;”
– style=“height: number;”
– style=“width: number;”
Special Characters
• &
– Ampersand
• ©
– Copyright
• ·
– Bullet
• ®
– Registered
• ™
– Trademark
<a>
• <a>…</a>
– Used to Create Links to Other Resources
– Named Anchor
• AKA Bookmark
• Used to Name Specific Locations within a Page
• id Attribute
– Defines Destination
• Attributes
– accesskey=“text”
• Character Used as Keyboard Shortcut to Activate Link
– coords=“X1, Y1, X2, Y2, etc.”
• Coordinates that Define Hot Spot Shape in Image Map
– href=“URL”
• Specifies Location of Linked Resource
– Typically Another HTML File
– Can Also Specify Other Internet Resources
» Files, E-mail, FTP
• Named Anchor or Bookmark URLs are Preceded By #
• Attributes
– name=“text”
• Marks Specific Place Within an HTML Document
• AKA Named Anchor or Bookmark
– rel=“text”
• Indicates Relationship Between Documents
– rel=“stylesheet”
» Tells that Browser Linked Document is a Style Sheet
– shape=“rect | circle | poly | default”
• Specifies Shape of Hot Spot in Image Map
• Attributes
– title=“text”
• Provides Supplemental Information Regarding a Link
– Behaves Like a Tooltip
Should be – Less Than 60 Characters
• Example
<a href="http://www.mysite.com/">A link to a
site.</a>
< a href="#P5">A link to paragraph 5 in same
document.</a>
<p>Paragraph 1</p>
<p>Paragraph 2</p>
<p>Paragraph 3</p>
<p>Paragraph 4</p>
<p id=“P5”>Paragraph 5 content.</p>
Paths
• URL (Uniform Resource Locator)
– Location of Document on Web
• www.
• Path
– Location of Document on Server
• http://www. /about/team/details/
• Absolute
– Exact Location on Server
• Begins with a /
– /student/index.htm
• Relative
– Location Relative to Current Document
• Current — Nothing
– page.htm
• Child — Separated by /
– images/background.gif
• Parent — Two Periods (..)
– ../page.htm
URL
• http://www. /about/team/details.html
– Communication Protocol
• http://
– Domain
• www.
– Path
• /about/team/
– Document
• details.html
Protocols
• Hypertext Transfer Protocol
– Web Server
– http://
• File Transfer Protocol
– File Server
– ftp://
• USENET
– Newsgroup
– <a href=“news:newsgroup.name”>Click Me</a>
• E-Mail
– Mailto
• <a href=“mailto: priyanka.desai@thakureducation.org”>Send
Mail</a>
– Can Automatically Include Subject Line
• “mailto: priyanka.desai@thakureducation.org?subject=text”
– Other Options
• “mailto: priyanka.desai@thakureducation.org?cc=another@sti2.at
bcc=secret@cod.edu&subject=subscribe
&body=Send me your newsletter right away”
<table>
• <table>…</table>
– Structure to Control Page Layout
– Structure to Contain & Align Content
• Attributes
– border=“#”
• Sets Thickness of Borders Displayed for Table Cells
• Attribute Set to 0 Will Make Borders “Invisible”
• Attributes
– cellpadding=“#”
• Specifies Amount of Space Between Cell & Content in Cell
– cellspacing=“#”
• Specifies Amount of Space Between Cells
– frame=“above | below | border | box | hsides | lhs | rhs |
void | vsides”
• Specifies Where Borders of Tables & Cells Appear
• Attributes
– height=“# | %”
• Specifies Height of Table in Pixels or Percentage of Window
– rules=“all | cols | groups | none | rows”
• Specifies Where Gridlines Appear in a Table
– valign=“top | bottom | middle ”
• Specifies Vertical Alignment of Text in Cells
– width=“# | %”
• Specifies Width of Table in Pixels or Percentage of Window
<colgroup>
• <colgroup>…</colgroup>
– Defines Groups of Table Columns for Formatting
– Only Valid Inside <table>
• Attributes
– align=“left | center | right | justify | char”
• Specifies Horizontal Alignment of Contents in Column Group
– char=“character”
• Specifies Character to Use to Align Text On
• Attributes
– span=“#”
• Specifies Number of Columns <colgroup> Should Span
– valign=“top | middle | bottom | baseline”
• Specifies Vertical Alignment of Contents in <colgroup>
– width=“# | %”
• Specifies Width of Each Column in <colgroup>
• 0* - Column Width Should be Minimum Width
W
<col>
• <col />
– Defines One or More Columns of Table for Formatting
– Only Valid Inside <table> or <colgroup>
• Attributes
– align=“left | center | right | justify | char”
• Specifies Horizontal Alignment of Contents in Table Column
– char=“character”
• Specifies Character to Use to Align Text On
• Attributes
– span=“#”
• Specifies Number of Columns the Column Should Span
– valign=“top | middle | bottom | baseline”
• Specifies Vertical Alignment of Contents in Table Column
– width=“# | %”
• Specifies Width of Column
• 0* - Column Width Should be Minimum Width
<tr> & <td>

• <tr>…</tr>
– Defines a Row in a Table
• <td>…</td>
– Defines Table Data (a Cell) in a Row
• Table Data Cells Must Only Appear Within Table Rows
• Closing Tag Must Appear on Same Line as Content
– Otherwise Gapping May Occur
<td>
• Attributes
– colspan=“#”
• Specifies How Many Columns the Cell Overlaps
– rowspan=“#”
• Specifies How Many Rows the Cell Overlaps
<th> & <caption>

• <th>…</th>
– Specifies the Table Header for a Row
• Identical to Table Data Cells Except:
– Cells Contents are Bolded
Cells – Contents are Centered
• <caption>…</caption>
– Attaches a Caption to a Table
How to make your Web page good looking

CASCADE STYLE SHEET
History of CSS
• Initial Proposal for CSS
– Released in 1994 by Hakon Lie of CERN
• World Wide Web Consortium (W3C)
– Founded in 1994 as a Web Standards Organization
• CSS1 (’96) — 50 Properties
– www.zvon.org/xxl/css1Reference/Output/index.html
• CSS2 (’98) — 70 Additional Properties
– www.zvon.org/xxl/css2Reference/Output/index.html
CSS Basics
• Style Rules
– Determines Style Characteristics for an HTML Element
– Selector
• Determines Element to Which Rule is Applied
– Declaration
• Details the Exact Property Values
– Property
Quality or Characteristic » Quality (e.g., Color)
– Value
» Specification of Property (e.g., Blue)
• Style Sheet
– Set of Style Rules
• Style Rule Syntax
Combining
CSS & HTML
• Inline
– Modify the Appearance of a Particular Element
• Style Attribute
• Embedded
– Applied To An Entire Document
• Redefines All Occurrences of a Particular Element
– Uses <style>…</style> in <head>
• Linked
– External File of Declarations Available to an Entire Site
• ASCII File with an Extension of .css
Inline Style
• Defines a Style for a Single Element
– Generally Used to Override a Style Set at a Higher Level
– Only Affects One Instance of an Element
• Syntax
< tag style=“property:value1; property:value2;”>
<h1 style=“color:green; font-family:sans-serif;”>
<b style=“color:yellow; background-color:green;”>
Embedded Style
• Always Contained in the <head>
– Generally Used to Override a Style Set at a Higher Level
– Only Affects the Document in which it Resides
• Syntax
– selector {declarations}
<style type=“text/css”>
h1 {color:green; font-family:sans-serif;}
b {color:yellow; background-color:green;}
</style>
Web Engineering (703512) 54 Linked StyleLinked Style
Linked Style
• External Style Sheet
– Always Contained in the <head>
– Text Document that Contains Style Rules
– Allows Specification of Rules for Multiple Documents
– Does Not Contain HTML Code
• Syntax
• <link rel=“stylesheet” href=“master.css” />
Cascading
• Determines Which Rules are Assigned to Elements
• Weight Assignment Based on Four Variables:
– Use of the !Important Keyword
– Origin of the Rule
– Specificity of the Selector
– Order of the Rule in the Style Sheet
• Rule Weight with the !Important Keyword
– Allows User to Override Author’s Style Setting
• For Particular Element
– Improves Accessibility p y of Documents
• Gives Control to Users with Special Requirements
• Rule Weight by Origin
– Cascading Order of Precedence:
1. Rules From Author’s Style Sheet
2. Rules From User’s Style Sheet
3. Rules From Browser’s Style Sheet
• Rule Weight by Specificity
– Rules with More Specific Selectors Take Precedence Over
Rules with Less Specific Selectors
• Rule Weight by g y Order
– Based on Order of Rule within Style Sheet
• Rules Listed Later Take Precedence Over Those Listed Earlier
gineering (703512
Inheritance
• Parent
– Element that Contains Another Element
• Child
– Element within Another Element
• Inheritance
– CSS Rules Inherit from Parent to Child Elements
• Based on Hierarchical Structure of Documents
Basic Selection
• Type Selectors
– Selector Determines Element to which Declaration is
Applied
– Style Sheet Examples:
• h2 {color: red;}
• p {font-size: 10 pt;}
• Grouping Selectors
– Set the Same Declaration for Multiple Selectors
• Syntax:
or
• h1, h2 {color: red;}
• Combining Declarations
– Multiple Declarations May be Stated for Same Selector
• Syntax:
• p {color: blue;}
• p {font-size: 12pt;}
or
• p {color: blue; font-size: 12pt;}
• Descendant Selector
– AKA Contextual Selectors
– Based on Hierarchical Structure of Elements in Document
• Syntax:
– b i {color: #336699; background-color: #000000;}
– Does Not Apply to i b
W
eb Engineering (703512) 66
Advanced Selection
• idAttribute Selector
– Applied to Only ONE Unique Element in a Document

– Core Attribute that can be Applied to Any HTML Element
• classAttribute Selector
– Enables Application of Rule to Selected Element(s)
– Core Attribute that can be Applied to Any HTML Element
• Syntax:
<p class=“quote”>Text in red with a 30 pixel margin</p>
– May be Restricted to a Specific Element Type
h1.quote {color: red; margin: 30px;}
• <div>…</div>
– Block Level Element
– Used to Contain Other HTML Elements
– Displayed Discretely p y y from the Rest of the Document
• Paragraph Breaks Added Before and After <div> Contents
• <span>…</span>
– Inline Element
– Used to Contain Other HTML Elements
– Used within Text Blocks
• Pseudo-Class Selectors
– Select Elements Based on Characteristics Other Than
Name
– Link Pseudo-Classes
• :link
– Allow Modification of Style Characteristics for Unvisited Links
:link {color: green;}
• :visited
– Allow Modification of Style Characteristics for Visited Links
:visited {color: green;}
• Pseudo-Class Selectors
– Dynamic Pseudo-Classes
• Apply Styles to an Element Based on User’s Actions
• :hover
– Applies Style When User Mouses Over Element
• :active
– Applies Style When User Activates Element
• :focus
– Applies Style When Element is Accepting User Input
eb Engineering (703512) 25
• Pseudo-Elements Selectors
– Modify Aspects of Document Not Classified by Elements
– :first-letter
• Apply Style Rules to the First Letter of Any Block-level Element
– Initial Capitals
– Drop Capitals
• Pseudo-Element Selectors
– :first-letter
• Pseudo-Element Selectors
– :first-line
• Apply Style Rules to the First Line of Any Block-level Element
• Child Selector
–>
• Apply Style Rules to Child Elements of Any Parent
div > blockquote {font-weight: bold;}
• First Child
– :first-child
• Apply Style Rules to the First Child Element of a Parent
div > p:first-child {font-weight: bold;}
• Adjacent Sibling
• Apply Style Rules to
– Elements that Share the Same Parent
Are Adjacent in – the Code
Fonts
• Measurement Units
– Absolute Units
• Specify a Fixed Value
• Cannot be Scaled to Client Display
– Use Only When Measurements of User Medium are Known
– Relative Units
• Enables Scalable Web Pages
– Adapt to Different Display Types & Sizes
– Recommended Method for Web Page Design
• Measurement Units
Font Properties
• Styles
– style=“font-family: fonts;”
• Allows Specification of Font Family Names
• Generic Font Families
– Allows Greater Portability Across Platforms
– Serif → Traditional Letter Form (e.g., Times)
– Sans-serif → Block Letters, Have no Serifs (e.g., Arial)
– Monospace → Fixed-width
» Every Letter has Same Horizontal Width
– Cursive → Resembles Handwriting (Limited Support)
– Fantasy → Primarily Decorative (Limited Support)
• Styles
• Specific Font Families
– Allows Specification of Particular Font-family
» Garamond, Impact
– User Must Have Font Installed on Machine
» If not, Browser Will Supply Default
• Example:
<p style=“font-family: arial;”>eb Engineering (703512) 81
• Styles
• Specifying Font Substitution
– Allows Specification of Alternate Fonts
» Uses Comma Separated List
– Browser Scans List for First Installed Font
» Otherwise, Browser Supplies Default
– Generic Font-family Names can be Used
• Example:
<p style=“font-family: verdana,arial,helvetica,sans-serif;”>
• Styles
style =“font-size: size | keyword | %;”

• Absolute Keywords
– xx-small
– x-small
– small
– medium
– large
– x-large
– xx-large
Font Properties
• Styles
– style=“font-size: size | keyword | %;”
• Relative Keywords
– Smaller | Larger
– Example
» Parent Element’s Size is Large
» Current Element’s Size is Set to Larger
» Result is that the Current Font Size will be X-large
• Percentage
– Example
» 50%, 150%, 200%
• Styles
– style=“font-style: normal | italic | oblique;”
– style=“font-variant: normal | small-caps;”
– style=“font-weight: normal | bold bolder lighter y g | | g | #;”
• # = 100 – 900 in Increments of 100
• 400 = Normal
• 700 = Bold
• Font Shortcut
– Allows Specification of Properties in a Single Statement
– Font-size & Font-family Required
• Must be in Order
– Line-height Must be Preceded by /
• Example:
<p style=“– style= font: 18pt/24pt arial bold;”>
Text Properties
• Styles
– style=“line-height: # | %;”
• AKA Leading
– style=“letter-spacing:
normal | #;”
• AKA Kerning
– style=“word-spacing:
normal | #;”
• AKA Tracking
• Styles
style=“text-decoration: none underline | overline | linethrough
| blink;”
– style=“text-transform: capitalize | uppercase | lowercase |none;”
• Styles
style=“vertical-align: baseline | sub | super | top | texttop
| middle | bottom | text-bottom | % | #;”
Visual Formatting Model

• Three Element Display Type Categories
– Block (e.g., Paragraphs)
• Contain Inline Boxes that Contain Element Content
– Inline
• Contain Content within the Block-level Elements
• Do not Form New Blocks of Content
– List-item
• Creates Surrounding Container and List-item Inline Boxes
– display: block | inline | list-item | none
Box Model
• Describes Rectangular Boxes that Contain Content
– Each Block-level Element is Displayed as a Box
– Each Content Box can have Margins, Borders, & Padding
Margin Properties
• margin: # | %
-Shorthand Property Sets All Four Individual Margins
• margin-left | margin-right | margin-top | marginbottom:

bottom: # | %
– Negative margins can be set to achieve special effects
Padding Properties
• padding: # | %
– Shorthand Property Sets All Four Individual Paddings
• Same Format as Margin
• padding-left | padding-right | padding-top |
padding-bottom: # | %
Border Properties
• border: style width color
– Shorthand Property Sets All Four Individual Borders
• Same Format as Margin
• border-style: keyword
–Keywords
• none
• dotted
• dashed
• solid
• double
• groove
• ridge
• inset
• outset
• border-width: thin | medium | thick | #
• border-color: value
Special Box Properties
• width: # | %
– Sets Horizontal Width of a Containing Box
• height: # | %
– Sets Vertical Height of a Containing Box
• float: left | right ght | none
– Sets Position of an Element to Left/Right of Parent Element
• clear: none | left | right | both
– Controls Flow of Text Around Floated Elements
• float & clear
Background Properties
• background-color: colorname | #
• background-image: url(imagename.gif)
• background-repeat: repeat | repeat-x | repeat-y |no-repeat
• background-position: % | length | keyword

• background-attachment: scroll | fixed
List Properties
• list-style-type: disc | circle | square | decimal |
decimal leading lower decimal-leading-zero | lower-roman | upper-
roman |
lower-greek | lower alpha | lower-latin | upper-alpha
| upper-latin | hebrew | armenian | georgian | cjkideographic
| hiragana | katakana | hira-ganairoha |
katakana-iroha | none
– Default = disc
– Allows Customization of the List Marker
• Syntax:
ul {list-style-type: circle;}
• list-style-type
• list-style-image: url(filename.ext)
– Allows Use of Image as List Marker
• Syntax:
ul {list-style-image: url(paw.gif);}
• list-style-position: inside | outside

– Default = inside
– Allows Placement of the List Marker
• Syntax:
ul {list-style-position: outside;}
Positioning Properties
• position: type position size
– type = static | relative | absolute | fixed
– position = top | left | bottom | right
– size = height | width
• div {position:absolute; left:130px; top:100px;}
• div {position:absolute; left:130px; top:100px; width:100px;}
• visibility: visible | hidden

– Specifies Whether an Element is Displayed or Hidden
• z-index: auto | #
– Specifies an Element’s Stacking Level
How to add some business logic to your Web page
JAVASCPRIPT
What’s a Scripting Language?
• Language used to write programs that compute inputs to another
language processor
– One language embedded in another
• Embedded JavaScript computes HTML input to the browser
• Shell scripts compute commands executed by the shell
• Common characteristics of scripting languages
– String processing – since commands often strings
– Simple program structure, define things “on the fly”
– Flexibility preferred over efficiency, safety
• Is lack of safety a good thing? (Example: JavaScript used for Web
applications…)
Web Engineering (703512)
JavaScript History
• Developed by Brendan Eich at Netscape
– Scripting language for Navigator 2
• Later standardized for browser compatibility
– ECMAScript Edition 3 (aka JavaScript 1.5)
• Related to Java in name only
– Name was part of a marketing deal
• Various implementations available
– SpiderMonkey C implementation (from Mozilla)
– Rhino Java implementation (also from Mozilla)
Common Uses of JavaScript
• Form validation
• Page embellishments and special effects
• Navigation systems
• Basic math calculations
• Dynamic content manipulation
• Sample applications
– Dashboard widgets in Mac OS X, Google Maps, Philips
universal remotes, Writely word processor, hundreds of
others…
Example 1: Add Two Numbers
<html>
…
<p> … </p>
<script>
var num1 num1, num2, sum
num1 = prompt("Enter first number")
num2 = prompt("Enter second number")
sum = parseInt(num1) + parseInt(num2)
alert("Sum = " + sum)
</script>
…
</html>Web Engineering (703512)
Example 2: Browser Events
<script type="text/JavaScript">
Mouse event causes
page function whichButton(event) {
defined if (event.button==1) {
alert("You clicked the left mouse button!") }
else {
page-function
to be called
alert("You clicked the right mouse button!")
}}
</script>
…
<body onmousedown="whichButton(event)">
…
</body>
Example 3: Page Manipulation
• Some possibilities
– createElement(elementName)
– createTextNode(text)
– appendChild(newChildpp ( )
– removeChild(node)
• Example: add a new list item
var list = document.getElementById('t1')
var newitem = document.createElement('li')
var newtext = document.createTextNode(text)
list.appendChild(newitem)
newitem.appendChild(newtext)
Language Basics
• JavaScript is case sensitive
– onClick, ONCLICK, … are HTML, thus not case-sensitive
• Statements terminated by returns or semi-colons
– x = x+1; sameas same as x = x+1
• “Blocks” of statements enclosed in { …}
• Variables
– Define using the var statement
– Define implicitly by its first use, which must be an
assignment
• Implicit defn has global scope, even if occurs in nested scope!
JavaScript Primitive Datatypes
• Boolean: true and false
• Number: 64-bit floating point
– Similar to Java double and Double
– No integer type
– Special values NaN (not a number) and Infinity
• String: sequence of zero or more Unicode chars
– No separate character type (just strings of length 1)
– Literal strings using ' or " characters (must match)
• Special objects: null and undefined
Objects
• An object is a collection of named properties
• Think of it as an associative array or hash table
– Set of name:value pairs
• objBob = { name: “Bob", grade: 'A', j ,g , level: 3};
– Play a role similar to lists in Lisp / Scheme
• New members can be added at any time
• objBob.fullname = 'Robert';
• Can have methods
• Can refer to this
Functions
• Functions are objects with method called “( )”
– A property of an object may be a function (=method)
• function max(x,y) { if (x>y) return x; else return y;};
• max.description = “return the maximum of two arguments”;
– Local declarations may appear in function body
• Call can supply any number of arguments
– functionname.length arguments : # of in definition
– functionname.arguments.length : # arguments in call
– Basic types are passed by value, objects by reference
• “Anonymous” functions
– (function (x,y) {return x+y}) (2,3);
Examples of Functions
• Curried functions
• function CurriedAdd(x) { return function(y){ return x+y} };
• g = CurriedAdd(2);
• g(3)
• Variable number of arguments
function sumAll() {
var total=0;
for (var i=0; i< sumAll.arguments.length; i++)
total+=sumAll.arguments[i];
return(total); }
sumAll(3,5,3,5,3,2,6)

Anonymous Functions
• Anonymous functions very useful for callbacks
– setTimeout(function() { alert("done"); }, 10000)
– Evaluation of alert("done") delayed until function call
• Simulate blocks by function definition and call
var u = { a:1, b:2 }
var v = { a:3, b:4 }
(function (x,y) {
var tempA = x.a; var tempB =x.b; // local variables
x.a=y.a; x.b=y.b;
y.a=tempA; y.b-tempB
}) (u,v) // Works because objs are passed by ref
Basic Object Features
• Use a function to construct an object
– function car(make, model, year) {
this.make = make;
this.model = model;
this.year = year; }
• Objects have prototypes, can be changed
– var c = new car(“Ford”,”Taurus”,1988);
– car.prototype.print = function () {
return this.year + “ “ + this.make + “ “ + this.model;}
– c.print();
JavaScript in Web Pages

• Embedded in HTML page as <script> element
– JavaScript written directly inside <script> element
• <script> alert("Hello World!") </script>
– Linked file as src attribute of the <script> element
• <script type="text/JavaScript" src=“functions.js"></script>
• Event handler attribute
• <a href="http://www.yahoo.com " onmouseover="alert('y ('hi');">
• Pseudo-URL referenced by a link
• <a href=“JavaScript: alert(‘You clicked’);”>Click me</a>
Language Features in This Class

• Stack memory management
– Parameters, local variables in activation records
• Garbage collection
• Closures
– Function together with environment (global variables)
• Exceptions
• Object features
– Dynamic lookup, encapsulation, subtyping, inheritance
• Concurrency
JavaScript eval
• Evaluate string as code
– The eval function evaluates a string of JavaScript code, in
scope of the calling code
var code = "var a = 1";
l( d ) eval(code); // a is now '1‘
var obj = new Object();
obj.eval(code); // obj.a is now 1
Unusual Features of JavaScript

• Eval, run-time type checking functions
• Support for pattern matching (reg. expressions)
• Can add methods to an object
• Can delete methods of an object
– myobj.a = 5; myobj.b = 12; delete myobj.a;
• Iterate over methods of an object
– for (variable in object) { statements }
1.What Is XML?
Extensible Markup Language (XML) is a buzzword you will see
everywhere on the Internet, but it’s also a rapidly maturing technology
with powerful real-world applications, particularly for the management,
display, and organization of data.
Of Data, Files, and Text

XML is a technology concerned with the description and structuring of
data, so before we can really delve into the concepts behind XML, we
need to understand how computers store and access data. For our
purposes, computers understand two kinds of data files: binary and
text files.
Binary Files
• A binary file, at its simplest, is just a stream of bits (1s and 0s).
It’s up to the application that created a binary file to understand
what all of the bits mean. That’s why binary files can only be
read and produced by certain computer programs, which have
been specifically written to understand them.
For example, when a document is created with Microsoft Word,
the program creates a binary file with an extension of “doc,’’ in
its own proprietary format. The programmers who wroteWord
decided to insert certain binary codes into the document to
denote bold text, codes to denote page breaks, and other codes
for all of the information that needs to go into a “doc’’ file. When
you open a document in Word, it interprets those codes and
displays the properly formatted text on-screen or prints it to the
printer.
For example, a word processing document has different meta
data than a spreadsheet document, because they are describing
different things. Not so obviously, documents from different word
processing applications also have different metadata, because
the applications were written differently. (see Figure 1-1).
• Binary file formats are advantageous because it is easy for

computers to understand these binary codes, meaning that they
can be processed much faster, and they are very efficient for
storing this meta data. There is also a disadvantage, as we’ve
seen, in that binary files are proprietary. You might not be able
too pen binary files created by one application in another
application, or even in the same application running on another
platform.
Text Files
• Like binary files, text files are also streams of bits. However, in a
text file these bits are grouped together in standardized ways, so
that they always form numbers. These numbers are then further
mapped to characters. For example, a text file might contain the
following bits: 1100001 the number 97
• Figure 1-2 shows some of the applications on my machine that
are capable of opening text files. Some of these programs only
allow me to view the text, while others will let me edit it, as well.
• The disadvantage of text files is that adding other information—

our meta data, in other words—is more difficult and bulky. For
example, most word processors allow you to save documents in
text form, but if you do, you can’t mark a section of text as bold
or insert a binary picture file. You will simply get the words with
none of the formatting.
A Brief History of Markup

A very well-known language, based on the SGML work, is the
HyperText Markup Language (HTML). HTML uses many of SGML’s
concepts to provide a universal markup language for the display of
information, and the linking of different pieces of information. The idea
was that any HTML document (or web page) would be presentable in
any application that was capable of understanding HTML (termed a
web browser). A number of examples are given in Figure 1-3.
So What Is XML?
• I could create an HTML document that displays information about
a person, but that’s about all I could do with the document. I
couldn’t write a program to figure out from that document which
piece of information relates to the person’s first name, for
example, because HTML doesn’t have any facilities to describe
this kind of specialized information. In fact, HTML wouldn’t even
know that the document was about a person at all. Extensible
Markup Language (XML) was created to address these issues.
• Note that it’s spelled “Extensible,” not “eXtensible.” Mixing these
up is a common mistake.
XML is a subset of SGML, with the same goals (markup of any
type of data), but with as much of the complexity eliminated as
possible. XML was designed to be fully compatible with SGML.
• If bandwidth is a critical issue for your applications, you can
always compress your XML documents before sending them
across the network—compressing text files yields very good
results.
HTML file like this:
<html>
<head><title>Name</title></head>
<body>
<p>John Doe</p>
</body>
</html>
I might create an XML file like the following:

<name>
<first>John</first>
<last>Doe</last>
</name>
Opening an XML File in Internet Explorer

In notepad save as follows
Fig-1.4
the out put is as follows
Fig-1.5
Hierarchies in XML
Fig-1.6
<name> is a parent of <first>. <first>, <middle>, and <last> are all
siblings to each other (they are all children of <name>). Note, also,
that the text is a child of the element. For example the text John is a
child of <first>.
XML Parsers
• Parsers are also available for parsing SGML documents, but they
are much more complex than XML parsers. Because XML is a
subset of SGML, it’s easier to write an XML parser than an SGML
parser.
<name>
<first>John</first>
<middle>Fitzgerald Johansen</middle>
<last>Doe</last>
</name>
• The parser can tell us that there is a piece of data called
<middle>, and that the information stored there is Fitzgerald
Johansen. The parser writer didn’t have to know any rules about
where the first name ends and where the middle name begins.
• Just as any HTML document can be displayed by any web
browser, any XML document can be read by any XML
parser, regardless of what application was used to create
it, or even what platform it was created on. This goes a
long way to making your data universally accessible.
• The <p> tag is a predefined HTML tag.
However, web browsers can’t understand the following:
<paragraph>This is a paragraph.</paragraph>
The <paragraph> tag is not a predefined HTML tag.
What Are the Pieces That Make Up XML?

Here are some of the more important ones:
• XML 1.0 is the base specification upon which the XML family is
built. It describes the syntax that XML documents have to follow,
the rules that XML parsers have to follow, and anything else you
need to know to read or write an XML document. It also defines
DTDs, although they sometimes get treated as a separate
technology.
• Because we can make up our own structures and element names
for our documents, DTDs and Schemas provide ways to define
our document types.
• Namespaces provide a means to distinguish one XML vocabulary
from another, which allows us to create richer documents by
combining multiple vocabularies into one document type.
• XPath describes a querying language for addressing parts of an
XML document. This allows applications to ask for a specific
piece of an XML document, instead of having to always deal with
one large chunk of information. For example, XPath could be
used to get “all the last names”from a document.
• As we discussed earlier, in some cases, we may want to display
our XML documents. For simpler cases, we can use Cascading
Style Sheets (CSS) to define the presentation of our documents.
For more complex cases, we can use Extensible Stylesheet
Language (XSL); this consists of XSLT, which can transform our
documents from one type to another, and Formatting Objects,
which deal with display.
• The XQuery recommendation is designed to provide a means of
querying data directly from XML documents on the web.
• To provide a means for more traditional applications to interface
with XML documents, there is a document object model (DOM),
which we discuss in Chapter 11. An alternative way for
programmers to interface with XML documents from their code is
to use the Simple API for XML (SAX).
• In addition to the specifications for the various XML technologies,
some specifications also exist for specific XML document types:
The RDF Site Summary (RSS) specification is used by web sites that
want to syndicate
news stories (or similar content that can be treated similarly to
news stories), for use by other web sites or applications.
The Scalable Vector Graphics (SVG) specification is used to describe
two-dimensional
Graphics.
Question 1
Modify the “name’’ XML document you’ve been working with to include
the person’s title (Mr., Ms., Dr., and so on).
Solution
Because of the self-describing nature of XML, the only hard part about
adding a title to our “name’’ example is deciding what to call it. If we
call it “title,’’we can add it to our document as follows:
<name>
<title>Mr.</title>
<first>John</first>
<last>Doe</last>
</name>
Another way to handle it might be to treat a title as a simple prefix to
the name; this would also
allow us the flexibility of adding a suffix. This approach might look like
the following:
<name>
<prefix>Mr.</prefix>
<first>John</first>
<last>Doe</last>
<suffix>the 3rd</suffix>
</name>
2.Well-Formed XML
Parsing XML
The main reason for creating all these rules about writing well-formed
XML documents is so that we can create a computer program to read
in the data, and easily tell markup from information.
According to the XML specification (http://www.w3.org/TR/REC-
xml#sec-intro): “A software module called an XML processor is used to
read XML documents and provide access to their content and
structure. It is assumed that an XML processor is doing its work on
behalf of another module, called the application.”
There are quite a number of XML parsers available, many of which are
free. Some of the
better-known ones include:
• Microsoft Internet Explorer Parser—Microsoft’s XML parser,
MSXML, first shipped with Internet Explorer 4, and implemented an
early draft of the XML specification. With the release of IE5, the XML
implementation was upgraded to reflect the XML version 1
specification. The latest version of the parser is available for
download from Microsoft’s MSDN site, at http://msdn.microsoft.com,
and also comes built-in with the Internet Explorer browser.
• Apache Xerces—The Apache Software Foundation’s Xerces
subproject of the Apache XML Project (http://xml.apache.org/) has
resulted in XML parsers in Java and C++, plus a Perl wrapper for the
C++ parser. These tools are free, and the distribution of the code is
controlled by the GNU Public License (GPL).
Since this XML layout will contain information about orders, we need
to capture information like the customer’s name and address, the type
of hardware which has been purchased, information about the
subscription to sernaDirect, and so on.
Figure 2.1 shows the hierarchy we’ll be creating:
save as order.xml
output:
Rules for Elements
XML documents must adhere to certain rules to be well
formed.
We’ll list them, briefly, before getting down to details:
• Every start-tag must have a matching end-tag, or be a self-
closing tag.
• Tags can’t overlap; elements must be properly nested.
• XML documents can have only one root element.
• Element names must obey XML naming conventions.
• XML is case sensitive.
• XML will keep whitespace in your PCDATA.
Elements Must Be Properly Nested
Which can be properly formatted in a tree, like this:
<P>
Some
<STRONG>
formatted
<EM>
text
</EM>
</STRONG>
<EM>
, but
</EM>
no grammar no good!
</P>
An XML Document Can Have Only One Root Element

• For example, the following XML is not well-formed, because it has
two root elements:
<name>John</name>
<name>Jane</name>
• To make this well-formed, we’d need to add a top-level element,
like this:
<names>
<name>John</name>
<name>Jane</name>
</names>
Elements Must Obey XML Naming Conventions

There aren’t any reserved words to avoid in XML, as there are in most
programming languages, so we have a lot of flexibility in this regard.
However, there are some rules that we must follow:
• Names can start with letters (including non-Latin characters) or
the - character, but not numbers or other punctuation
characters.
• After the first character, numbers, hyphens, and periods are
allowed.
• Names can’t contain spaces.
• Names can’t contain the : character. Strictly speaking, this
character is allowed, but the XML specification says that it’s
“reserved.’’ You should avoid using it in your documents, unless
you are working with namespaces (which we’ll be looking at in
the next chapter).
• Names can’t start with the letters xml, in uppercase, lowercase,
or mixed—you can’t start a name with xml, XML, XmL, or any
other combination.
XML Declaration
It is often very handy to be able to identify a document as being of a
certain type. On computers running Windows, giving the file an
extension of .xml identifies the file as an XML file to Windows, but on
other operating systems this will not work. Also, we might want the
flexibility of creating XML files with other extensions.
Case Sensitivity
Warning! Because XML is case sensitive, you could legally create an
XML document that has both <first> and <First> elements, which
have different meanings. This is a bad idea, and will cause nothing but
confusion! You should always try to give your elements distinct names,
for your sanity, and for the sanity of those to come after you.
Whitespace in PCDATA
• In XML, the whitespace stays.
This is a paragraph. It has a whole bunch
of space.
• In HTML
<P>This is a paragraph. It has a whole
bunch<BR> of space.</P>
Question 1
For the addresses in our Order XML, we used a common format of
“Address Line 1, Address Line 2, City, State, and Zip Code.’’ Other
applications need to be stricter with their addresses, and have
separate elements for street number, street name, and so on. Rewrite
the last version of the Order XML using the following information,
instead of the Address Line 1/Address Line 2 format:
❑ Street Number
❑ Street Name
❑ Apt. Number
❑ City
❑ State
❑ Zip Code
❑ Additional Information
Solution
As always, there are multiple ways this could be designed. One option
might be to use attributes, to break up information about the street
and the apartment, like this:
3.XML Namespaces
Question 1
Earlier we had the following XML document, in which we had to cancel
the default namespace:
<employee>
<name>Jane Doe</name>
<notes>
<p xmlns="http://www.w3.org/1999/xhtml">I've worked
with <name xmlns="">Jane Doe</name> for over a <em>year</em>
now.</p>
</notes>
</employee>
Assuming that this document is for the fictional Serna Ferna, Inc.,
company we’ve been using, create a namespace for employees, and
use it in this document. Be sure to keep the XHTML elements in their
namespace.
Solution
The URL we’ve been using for namespaces for Serna Ferna, Inc., has
been http://www.sernaferna .com, followed by something to indicate
the namespace being named. In this case, because we’re creating a
namespace for employees, so http://www.sernaferna.com/employee
makes sense.
Because we have a <name> element embedded inside an XHTML <p>
element, it makes sense to use prefixes, rather than default
namespaces, so the resulting document could look like this:
Validation
4.Document Type Definitions
The need to validate documents against a vocabulary is common in
markup languages. In fact, it is so common that the creators of XML
included a method for checking validity in the XML Recommendation.
An XML document is valid if its content matches its definition of
allowable elements, attributes, and other document pieces. By utilizing
special Document Type Definitions, or DTDs, you can check the
content of a document type with special parsers. The XML
Recommendation separates parsers into two categories—validating
and nonvalidating. Validating parsers, according to the
Recommendation, must implement validity checking using DTDs.
Therefore, if we have a validating parser, we can remove the content-
checking code from our application and depend on the parser to verify
the content of our XML document against our DTD.
The External DTD
In our example, we created a relatively simple DOCTYPE declaration;
we will look at some more
advanced DOCTYPE declaration features later.
<!ELEMENT name (first, middle, last)>
<!ELEMENT first (#PCDATA)>
<!ELEMENT middle (#PCDATA)>
<!ELEMENT last (#PCDATA)>
At this point we have completed the DTD. All of the children that were
listed in content models
now have their own element declarations. The final DTD should look
like the following:
<!ELEMENT dinosaurs (carnivore, herbivore, omnivore)>
<!ELEMENT carnivore (species, length, height, weight, speed, weapon,
discoverer, location, description)>
<!ELEMENT herbivore (species, length, height, weight, speed, weapon,
<!ELEMENT omnivore (species, length, height, weight, speed, weapon,
<!ELEMENT species (#PCDATA)>
<!ELEMENT length (#PCDATA)>
<!ELEMENT height (#PCDATA)>
<!ELEMENT weight (#PCDATA)>
<!ELEMENT speed (#PCDATA)>
<!ELEMENT weapon (part-of-body, description)>
<!ELEMENT part-of-body (#PCDATA)>
<!ELEMENT description (#PCDATA | b | i)*>
<!ELEMENT b (#PCDATA)>
<!ELEMENT i (#PCDATA)>
<!ELEMENT discoverer (name, year)>
<!ELEMENT name (#PCDATA)>
<!ELEMENT year (#PCDATA)>
<!ELEMENT location (GPS | (country, region))>
<!ELEMENT GPS (#PCDATA)>
<!ELEMENT country (#PCDATA)>
<!ELEMENT region (#PCDATA)>
Save the file as dinosaurs.dtd.
XPath
When writing code to process XML, you often want to select specific
parts of an XML document to process in a particular way. For example,
you might want to select some invoices that fit a date range of
interest. Similarly, you may want to specifically exclude some part(s) of
an XML document from processing. For example, if you make basic
human resources data available on your corporate intranet, you
probably want to be sure not to display confidential information such
as salary for an employee. To achieve those basic needs, it is essential
to have an understanding of a technology that allows you to select a
part or parts of an XML document to process. The XML Path Language,
XPath, is designed to allow the developer to select specific parts of an
XML document.
XPath was designed specifically for use with Extensible Stylesheet
Language Transformations (XSLT), , and with XML Pointer (XPointer),
which is not discussed in detail in this book. More recently, XForms 1.0
makes use of XPath 1.0, too.
Serialized Document
In a serialized XML document we write start and end tags and, except
in XML documents of trivial length, there is a nested structure of
elements, such as in the following simple document:
<?xml version="1.0" encoding="UTF-8"?>

<Book>
<Chapter>Some content</Chapter>
<Appendix>Some appendix content.</Appendix>
</Book>
By now, you should be familiar with such XML documents and how to
write well-formed XML. But how are these documents represented in
the XPath data model?
XPath Data Model

The XPath data model represents most parts of a serialized XML
document as a tree of nodes. Most parts, but not all, of an XML
document are represented as nodes in the XPath data model. A root
node represents the document itself. An element node represents each
element in an XML document. Each attribute is represented by an
attribute node and so on, for comments and processing instructions. A
text node represents an element’s text content. In-scope namespaces
are represented by namespace nodes. We will look in more detail at
each type of node in a moment.
A few parts of an XML document are not represented in the XPath data
model. An XML declaration, if present, is not represented in any way in
the XPath data model, nor is a document type declaration (DOCTYPE
declaration) represented. In addition, while comments and processing
instructions can be represented by comment nodes and processing
instruction nodes, any comments and processing instructions
contained in the document type declaration are not represented at all
in the XPath data model.
The Document Object Model

Like the XPath data model, the Document Object Model represents an
XML document as a hierarchical tree of nodes. The types of nodes used
in the DOM are different from those used in XPath. The nodes used in
the DOM and writing code to manipulate the DOM.
Context
In XPath, the context indicates the location of the node where a
processor is currently situated, so to speak. That node is called the
context node.
However, the context consists of more than just the context node. It
also includes a context position and a context size. Consider the
following XML document:
<Book>
<Chapter number="1">This is the first chapter</Chapter>
<Chapter number="2">This is the second chapter</Chapter>
<Chapter number="3">This is the third chapter</Chapter>
<Chapter number="4">This is the fourth chapter</Chapter>
<Chapter number="5">This is the fifth chapter</Chapter>
</Book>
Suppose the context node is the node that represents the
Chapterelement node for the second chapter. We can use the
position()and last()functions, which are described in more detail later in
this chapter, to show the position of the context node and the context
size.
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform" >
<xsl:template match="/">
<html>
<head> <title>This shows the context position and context
size.</title>
</head>
<body>
<h3>Context position and context size demo.</h3>
<xsl:apply-templates select="/Book/Chapter" />
</body>
</html>
</xsl:template>
<xsl:template match="Chapter">
<xsl:if test="position()=2">
<p>When the context node is the second <b>Chapter</b> element
node then</p>
<p>the context position is <xsl:value-of select="position()" /></p>
<p>and the context size is <xsl:value-of select="last()" />.</p>
<p>The text the <b> Chapter</b> element node contains is
'<xsl:value-of select="." />'.
</p> </xsl:if>
</xsl:template>
</xsl:stylesheet>
The simple HTML document created by the stylesheet is shown in
Figure.
The ﬁles Books.xml, Books.xsl,andBooks.htmlare included in the code
download. The instructions to run the code are described in XSLT.
Notice that in the value of the selectattribute of the xsl:value-
ofelement you see the position() function and the last()function. As you
see in Figure 7-1, the context position is 2 and the context size is 5.
In addition to the context node, the context position, and the context
size, the context also includes variable bindings that are in scope,
namespace declarations that are in scope, and a function library (the
XPath 1.0 function library).
What Is a Node?
A node is a representation in the XPath data model of a logical part of
an XML document.
In XPath 1.0 there are seven types of nodes:
❑Root node
❑Element node
❑Attribute node
❑Text node
❑Namespace node
❑Comment node
❑Processing Instruction node
Each node type is described in more detail in the following sections.
Root Node
The root node represents the document itself, independent of any
content it has. The root node is the apex of the hierarchy of nodes that
represents an XML document. The element node, which represents the
document element, is a child node of the root node. The root node may
also have child nodes, which are processing instruction nodes or
comment nodes that correspond to any processing instructions or
comments in the prolog of the serialized XML document.
The XML declaration and the document type declaration are not
children of the root node. Neither of those features of a serialized XML
document is represented in the XPath data model.
The root node’s text value is the concatenation of the values of all
descendant text nodes of the root node, in document order. Examine
the following XML document:
<MixedContent>
Mary had a <Emphasis>little</Emphasis> lamb.
</MixedContent>
The text value of this document is Maryhadalittlelamb.
The root node does not have a name.
Element Node
Each element in an XML document is represented as an element node
in the XPath data model.
Element nodes have a name made up of the namespace URI of the
element and the local part of its name. For developers it is easier to
work with a qualiﬁed name, also called a QName, which is a
namespace prefix followed by a colon character followed by the local
part of the element type name:
prefix:localpart
The string value of an element node is the concatenation of the values
of all its descendant text nodes, in document order.
An element node may represent an element that possesses a unique
ID attribute. If it does, the id() function can be used to access that
element node.
Attribute Node
Each attribute in an XML document is represented in the XPath model
as an attribute node. The element node with which the attribute node
is associated is said to be the parent node of the attribute
node.Attribute nodes have a name and a string value.
Text Node
Text content of an element node is represented in the XPath data
model as a text node.
The string value of a text node is its character data. A text node does
not have a name.
Namespace Node
All in-scope namespaces of an element node are represented as
namespace nodes. XPath takes an extravagant approach to
namespace nodes. Each element node has its own namespace node for
all in-scope namespaces. For example, imagine the XPath model of the
following code:
<Book xmlns="http://www.XMML.com/booknamespace">
<Chapter number="1">Some text content.</Chapter>
<Chapter number="2">Some different text content.</Chapter>
</Book>
The Bookelement node has a namespace node associated with the
namespace URI http://www.XMML .com/booknamespace. Each of the
Chapterelement nodes also has its own namespace node associated
with the same namespace URI,
http://www.XMML.com/booknamespace. This simple document has
three separate namespace nodes associated with the same
namespace URI. In complex
documents, large numbers of namespace nodes can be associated with
a single URI and some elements deep in the hierarchy can have
several namespace nodes.
The name()function returns the namespace prefix associated with the
namespace node. The self:: node()expression (which can be
abbreviated to a period character) returns the namespace URI of the
namespace node.
Comment Node
A comment node represents a comment in the XML document.
Comments in the document type declaration are not represented in the
XPath data model.
Processing Instruction Node
A processing instruction node in the XPath model represents a
processing instruction in the corresponding XML document. Processing
instructions in the document type declaration are not represented in
the XPath data model.
The name of a processing instruction node is its target (turn to Chapter
2 for more on processing instructions). The string value of a processing
instruction node is its content, excluding the target.
XPath 1.0 Types
XPath 1.0 has four expression types:
❑boolean
❑node-set
❑number
❑string
Booleans
In an XPath 1.0 expression a boolean value is written as one of the
values true()or false(). You may wonder why we don’t simply use the
values trueand false. It is possible that an XML developer might choose
to have a structure like this:
<true> ... some content
</true>
True is a legal XML name, and can be used to name an element.
As you’ll see later, the XPath way to select the trueelement node is
indistinguishable from the value true. By using the syntax true()and
false(), which technically are XPath functions, we remove the possible
ambiguity.
Node-Sets
A node-set is a set of XPath nodes. Technically, an XPath 1.0 node-set
is unordered. However, when used in XSLT, which is currently XPath’s
main use, processing of a node-set is always in the document order of
the nodes for forward axes and in reverse document order for reverse
axes. XPath axes are discussed later. Most axes, including the
childaxis, are forward axes.
Consider what document order means by examining the following
simple document:
<PurchaseOrder>
<Date>2005-01-01</Date>
<To>XMML.com</To>
<ShippingAddress>
<Street>123 Any Street</Street>
<City>Anytown</City>
<State>AZ</State>
</ShippingAddress>
<ZipCode>12345</ZipCode>
</PurchaseOrder>
The PurchaseOrderelement is first in document order. Document order
among the children of the PurchaseOrderelement is then Date, To,
ShippingAddress, and ZipCode. All the child nodes of
ShippingAddresscome earlier in document order than the
ZipCodeelement.
Numbers
In XPath, numbers are floating point numbers. There is no way to
directly represent an integer in XPath, although numeric functions will
typically return a whole number from, for example, the count()
function, which counts the number of nodes in a node-set.
Strings
A string value in XPath is a sequence of Unicode characters. Generally,
like XML, XPath is not limited to ASCII characters but uses the much
more extensive Unicode character set.
XPath 1.0 has no type corresponding to a date. All dates are treated in
XPath as strings. So, for example, manipulation of strings that
represent dates to extract the month from a date depends on knowing
exactly how the string is written, and on using various XPath string
manipulation functions.So far, we have talked about XPath in a pretty
abstract way. How is XPath written?
XSLT
XSLT, Extensible Stylesheet Language Transformations, is a very
important XML language in many XML workflows. In many business
situations, data is either stored as XML or can be made available from
a database as XML. XSLT is important because, typically, the way XML
is stored needs to be changed before it is used. Wherever the data
comes from, the XML might need to be presented to end-users or
might need to be shared with business partners in a format that is
convenient for those business partners. XSLT plays a key role in
converting XML to its presentation formats and restructuring XML to fit
the structures useful to business partners.
In this chapter we will learn:
❑ How XSLT can be used to convert XML for presentation or
restructure XML for business-to-business data interchange.
❑ How XSLT differs from conventional procedural languages.
❑ An XSLT transformation is described in terms of a source document
and a result document. However, under the hood, the transformation
taking place is a source tree (which uses the XPath data model) to a
result tree (which also uses the XPath data model).
❑ How the elements that make up an XSLT stylesheet are used. For
example, we look at how to use the xsl:value-of element to retrieve
values from the source tree which is being transformed, and look at
the xsl:copy and xsl:copy-of elements which, respectively, shallow
copy and deep copy nodes from the source tree.
❑ How to use XSLT variables and parameters.
What Is XSLT?
XSLT is a declarative programming language, written in XML, for
converting XML to some other output. Often the output is XML or
HTML, but in principle, XSLT can produce arbitrary output from any
given XML source document. For example, an XML document can be
restructured to conform to a business partner’s schema, or a selection
from an XML document can be made to correspond to specified
criteria, such as selecting invoices from a specified period. XSLT uses
XPath, to select the parts of the source XML document that are used in
the result document. All the XPath 1.0 functions are available to an
XSLT processor, and XSLT 1.0 has a few functions of its own.
How Does an XSLT Processor Work?

A slightly more detailed description of an XSLT processor is that it
accepts a source document and creates an in-memory tree
representation of that source document, according to the XPath data
model, called the source tree. The XSLT processor processes the
source tree according to the templates that are contained in the XSLT
stylesheet. A result tree is created. The creation of a result tree from a
source tree is called transformation. After the result tree is created, a
process called serialization takes place that creates a familiar,
serialized XML (or other) document from the result tree.
Strictly speaking, an XSLT 1.0 processor is responsible only for the
transformation of the source tree to the result tree. However, most
XSLT processor software also contains an XML parser that creates the
source tree and a serializer component that serializes the result tree.
Running the Examples

Introducing the Saxon XSLT Processor
using Saxon 7.8 since I will make use of its XQuery 1.0 functionality
Installing the Saxon XSLT Processor
To check whether you have a Java Virtual Machine correctly installed,
open a command window and type the following:
java –version
If Java is installed, then you will see a message similar to the following:
java version "1.4.2"
Java (TM)2 Runtime Environment, Standard Edition (build 1.4.2-b28)
Java HotSpot (TM) Client VM (build 1.4.2-b28, mixed mode)
After you have completed the installation, open a command prompt
window. Add the command prompt type
java –version
and hit Enter. If a Java virtual machine has been successfully installed,
then a message similar to the one shown earlier will be displayed
If you want to be able to run saxon7.jar from any directory you will
need to add the file, giving its full path, to your CLASSPATH
environment variable.
To create or edit the CLASSPATH environment variable on Windows XP,
click Start, select Control Panel, and select the System option. On the
System Properties window, select the Advanced tab and click the
Environment Variables button toward the bottom of that tab. The
Environment Variables window opens.
In the System Variables section look at the existing environment
variables to see if CLASSPATH or classpath (it isn’t case sensitive) is
already present. If it is, then click the Edit button; the Edit System
Variable window opens. Edit the Variable Value text box to reflect the
location where you installed Saxon and the version that you chose to
install. Once you are sure that you correctly typed the location click
OK.
If there is no CLASSPATH variable in the System Variables section, then
look at the User Variables section to check whether it isn’t there.
Assuming that it isn’t, click the New button in the System Variables
section. The New System Variable window opens. Enter CLASSPATH
(either case) in the Variable Name text box and enter the location of
Saxon in the Variable Value text box. Figure shows the New System
Variable window with the CLASSPATH variable added. Click OK.
If you have a command prompt window open, you need to restart it so
that the changes you made to the environment variables are applied to
it.
Now you can test if the installation of Saxon is working correctly.
Navigate to the directory where you intend to install your XML source
files and your XSLT stylesheets. For the purposes of this chapter, they
are installed on my machine at c:\BXML\Ch08. At the command prompt
type the following:
java -jar saxon7.jar
If everything is working correctly, you will see the default Saxon error
message, which includes information about how to use the command-
line switches, shown in Figure 8-2 indicating that you haven’t entered a
full command to make Saxon carry out a transformation. At the
moment we don’t need to do anything more because the display of
that error message is an indication that Saxon is installed correctly. We
are almost ready to run our first XSLT example, but next we will look
briefly at how procedural and declarative programming languages
differ.
Procedural versus Declarative Programming

Many newcomers to XSLT find it tough to adjust to the difference in
approach when using XSLT compared to using procedural
programming languages. The following brief sections highlight the
differences between the two approaches.
Procedural Programming
When using a procedural programming language such as JavaScript,
you tell the computer step by step what you want to do. You might
define a function, and then you define each thing that the computer is
supposed to do, assigning a variable, iterating through a loop, and so
on. The mental picture of what the function is supposed to achieve
exists only in your mind.
Declarative Programming
The procedural programming approach contrasts with declarative
programming where you tell the computer what you want to achieve.
XSLT resembles SQL in that respect. For example, in SQL you tell the
relational database management system (RDBMS) to SELECT certain
columns, but you don’t expect to tell it how to retrieve the desired
data. XSLT is similar. You specify what the XSLT processor is to create
each time it comes across a particular pattern in the source tree.
To specify what the XSLT processor is to do you frequently use the
xsl:template element with a match attribute that contains the relevant
pattern. So if you wanted to create certain output for every Chapter
element in a source XML document you would have code like this:
<xsl:template match="Chapter">


</xsl:template>
Notice how the pattern Chapter appears as the value of the match
attribute of the xsl:template
element.
Let’s move on and create a simple XSLT stylesheet and look at how it
works.
Foundational XSLT Elements
We will create an example that makes a simple HTML web page from
the XML source document shown here:
<People>
<Person>
<Name>George H.W. Bush</Name>
<Description>George Bush was a late 20th century politician who was
elected as President of the United States.</Description>
</Person>
<Person>
<Name>Winston Churchill</Name>
<Description>Winston Churchill was a mid 20th Century British
politician who became famous as Prime Minister during the Second
World War.</Description>
</Person>
<Person>
<Name>John F. Kennedy</Name>
<Description>JFK, as he was affectionately known, was a United States
President who was assassinated in Dallas, Texas.</Description>
</Person>
</People>
As you can see the file, People.xml, contains brief information about
three famous twentieth-century politicians.
The following stylesheet, People.xsl, creates a simple HTML web page,
People.html, which
contains the name and description information about the politicians.
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0" >
<xsl:template match="/">
<html>
<head>
<title>Information about <xsl:value-of
select="count(/People/Person)" />people.</title>
</head>
<body>
<h3>Information about <xsl:value-of
select="count(/People/Person)" />people.</h3>
<br />
<xsl:apply-templates select="/People/Person" />
</body>
</html>
</xsl:template>
<xsl:template match="Person">
<h3><xsl:value-of select="Name" /></h3>
<p><xsl:value-of select="Description" /></p>
<br />
</xsl:template>
</xsl:stylesheet>
The HTML page created by the transformation is shown in Figure

CHAP 5 Web Application Modeling
Overview
• Introduction
• Model Driven Development
• Reference Scenario
• Content Modeling
• Hypertext Modeling
• Presentation Modeling
• Overview of Other Modeling Methods
Why do we need modeling?

5.1 INTRODUCTION
Why Create Models?

• Define an abstract view of a real-world entity
– Finding & discovering objects/concepts in a domain
– Assigning responsibilities to objects
• Tool of thought
– Reduce complexity
– Document design decisions
• Means of communication
5.2 Fundamentals of Web Application Modeling

Models are used to reduce complexity, document design decisions, and
facilitate communication within project teams. Modelling is aimed at
providing a specification of a system to be built in a degree of detail
sufficient for that system’s implementation. Figure shows the relevant
aspects of modeling,the scope of modeling spans along three
orthogonal dimensions.
Software Application Modeling
• Levels – the “how” & “what” of an application
• Aspects – objects, attributes, and relationships;
function & processes
• Phases – Development cycle(Refinement steps )
Modelling in software focuses on behavioral aspects to fulfill the needs
of programming languages.Today ,it is mainly based on an object-
oriented approach.
UML (OMG 2004 ,Hitz et al.2005)is an object-oriented modeling
language ,it forms the basis of most modeling methods for WEB
applications. UML has 2 types of diagrams:
structural diagrams such as class ,component, composite structure and
deployment as well as behavioral diagrams:such as use case,state
machine and activity diagram.
5.3 Modeling Specifics in Web Engineering

Traditional modeling languages (such as UML) do not provide
appropriate concepts for the specification of hyperlinks.This was the
reason why special modeling approaches foe the Web applications
have been developed during the past few years,which allow to address
a Web application in the three dimensions introduced above ,i.e.,
levels, aspects ,and phases.
Web Application Modeling(Requirements of Web application

modeling)
• Levels – Information(content), node/link structure(hypertext), UI &
page
layout separate(presentation).
Benefits of Level Separation
• model evolution
• layered model stack
• different hypertext structure on top of the same
content
• different presentation models on top of the same
hypertext model
• different modeling objectives

• content: no redundancy vs.
• hypertext: planned redundancy, i.e., information may
be retrieved via different navigation paths
• Aspects – Same as Software(Web) Applications.The relevance of

structure and behaviour depends on the type of web application to be
implemented. e.g.: E-commerce appln ,search engine
• different amount of structure and behaviorless
behaviour in static website applications
focus on behaviour in highly interactive applications
• unified modeling approach recommendable
• Phases –Approach depends upon type of application. Model –based

development in web engineering
•no general agreed process for web applications yet
•different approaches
information-driven (“content first”)
presentation-driven (“layout first”)
prototype-driven, agile (“test first”)
• Customization – Context information

adaption (customization), evolution to be taken into
account!
•on all levels
•of all aspects
•during all phases
Web Modeling
• Modeling static & dynamic aspects of content,
hypertext, and presentation
• We focus on object-oriented analysis & design
– Analysis: Finding & discovering classes of objects/
concepts in a domain
– Design: Defining software objects & how they interact to
fulfill requirements.
Objects
• Software entities – like real-world entities - that
consist of states and behaviors
• States:
– Variables store the states of an object’s properties
– Hidden from the outside world (data encapsulation)
• Behaviors:
• Methods define the object’s behaviors
• Used by objects to communicate with other objects
• Classes
– blueprints for creating objects of a particular type
Discovering Objects in a Domain

• The way we represent a domain’s software model should resemble
the physical model as closely as possible
• To find key classes of objects:
– Reuse existing models, if they exist
– Make a category list
• People, places, things
• Transactions
• Events
– Identify noun phrases
• When naming classes, use terms that are commonly used in the
domain
– i.e., terms users would understand
Assigning Responsibilities
• Responsibilities are an object’s obligations, or behaviors related to its
role in the system
• What does an object do?
– Doing something (to) itself
– Pass actions (messages) to other objects
– Controlling & coordinating the activities in other objects
• What does an object know?
– Private, encapsulated data
– Its related objects
– Items it can derive or calculate
From sketch models to code models

MODEL Driven DEVELOPMENT
Why Models at All?

• When it comes down to it, the real point of software development is
cutting code
• Diagrams are, after all, just pretty pictures
• No user is going to thank you for pretty pictures; what a user wants is
software that executes
Unified Modeling Language (UML)

• “The Unified Modeling Language is a visual language for specifying
and documenting the
artifacts of systems.”
• Language of choice (and ISO standard) for
diagramming notation in OO development
– Structural – Class diagrams (domain models)
– Behavioral –Use Cases, Sequence diagrams
• Currently at version 2.0, although many analysts and designers still
use 1.0
The Role of Model in the Development

Model - Code Interplay
Model-Driven ...
• Systematic development on basis of models
• Models become the first hand artifacts in the software development
cycle
• Key concepts
– abstraction from implementation detail
– systematic transformations
• Related Terminology
– Model Driven [Software] Engineering (MDE),
– Model Driven [Software] Development (MDD/MDSD),
– Model Driven Architecture (MDA)
– Model Driven Web Engineering (MDWE)
What is Model Driven Architecture?
• MDA is defined and developed by the Object Management Group
(OMG) since March 2001
• MDA is:
– "Model-Driven …"-framework for software development, defined by
the OMG
– open, vendor-neutral approach to interoperability using OMG's
modeling specifications:
• Unified Modelling Language (UML), Meta-Object Facility (MOF) and
Common Warehouse Model (CWM)
• Main ideas:
– Addresses the complete system development life cycle
– Separate specification from implementation
– Specify a system that is independent of a platform
– Transform a platform-independent (PIM) system specification into a
specific platform (PSM)
– Code generation
Model-Driven Development (MDD)

The Vision
• Should go far beyond the notion of CASE tools of the 80’s
• Reduced gap between problem and realization domain
– models as primary artefact throughout the lifecycle instead of code
– models as program instead of models as sketch/blueprint
• Systematic transformations of abstract models to concrete
implementations
– multiple levels of abstractions, (e.g., OMG’s PIM, PSM and PDM)
– horizontal (M2M) and vertical (M2C) transformations
• Standards for uniform storage, exchange, and transformation of
models, e.g., OMG’s
– MOF (Meta Object Facility) and Eclipse’s realization “Ecore”
– XMI (XML Metadata Interchange) and
– OCL (Object Constraint Language)
Developing in the MDA

Modeling Methods (not all are MDA)
UML for Web Engineering

• The book adopts the UML Web Engineering (UWE) notation
– UML-compliant
– Comprehensive modeling tool
– Download it here: http://www.pst.ifi.lmu.de/projekte/uwe/
– Requires MagicDraw UML (the free edition is enough)
• In the next lecture we will see WebML in details
A simple walkthrough case study

REFERENCE SCENARIO
The Conference Review System
• This case study was presented at IWWOST 2001 to compare different
Web application modeling methods
• The purpose of the system is to support the process of submission,
evaluation and selection of papers for a conference.
• Reviewed methods includes:
– UWE
– OOHDM
– WSDM
– WEBML
Actors I
• PC Chair
– creating the conference
– determining the conference topics (or tracks) and subjects
– establishing the Program Committee
– defining the final list of accepted and rejected papers
– defining the conference deadlines: submission, review, and
notification.
• PC Member
– evaluating a set of papers assigned to him
– indicating another person as a reviewer of a paper
– advising the PC Chair for the final list of accepted papers
Actors II
• Reviewer
– responsible for reviewing a paper
• Author
– submitting a paper for acceptance at the conference
– PC Members and Reviewers may also be Authors, they must have
different Ids for each role
Functions I: Paper Submission

• Any registered author may submit a paper
– The author must register: the title, the abstract, the conference track,
and a set of subjects chosen from a list previously determined by the
PC Chair, if there is one
– The system, after checking the authors’ registrations, assigns a paper
ID to the new paper, and allows the user to submit it by uploading a
file
– At any moment, an author is allowed to check the data about his
submitted papers. Until the submission deadline, the author is also
allowed to substitute the uploaded file by
a new one, or to change any of the informed data about the paper
Functions II: Assignment of Papers to PC Members

• The PC Chair may indicate potential conflicts of interest between PC
Members and submitted papers
• Once the submission deadline has been reached
– PC Members may indicate their interest and also conflicts of interest
with some papers
– In case of conflict of interest, the PC Member will not see any
information about the paper
– The PC Chair assigns papers to PC Members for reviewing, an email
message with the list of papers, and a URL to a page where he can
access these papers is sent
Functions III: Entering a Review

• A PC Member, or a Reviewer, may enter a review for a paper
assigned to him
• The review is entered by accessing a form containing all the
evaluation items
• A PC Member may see other reviews (entered by others) for any of
the papers he is reviewing, but only after he has entered his own
review
• The PC Chair has full access to all papers and all reviews
Function IV: Choosing Accepted

and Rejected Papers
• Once the review deadline has been reached, the review process is
closed
• The PC Chair, taking into account the recommendations of the PC
Members and
reviewers, chooses the papers that will be accepted and rejected
• Once the process is marked as finalized by the PC Chair, the system
issues a notification message to paper authors, which includes the
appropriate parts of the reviews submitted by the PC Members and
reviewers
5.4 Modeling requirements
How to model the data underlying a Web application
The overall functionality of Web application is modeled as a set of use
cases, which describe the Web application requirements from the
actors(people and other systems) perspectives. Aditionally, use cases
can be supplemented by UML activity diagrams to describe the
functional requirements in more detail.
5.5 CONTENT MODELING

Modeling the content in the sense of pure data modeling is normally
sufficient for Static Web applications. Complex Web applications
additionally require the modeling of behavioral aspects.This means
that the content modeling includes the creation of the problem domain
model,consisting of static and dynamic aspects, as known from the
traditional Software Engineering.In addition the following Web
application characterictics have been taken into account:
– Document centric charater and multimedia:It is necessary to
take all kinds of different media formats into account when
modeling the content, including the structures the information is
based on.
– Integration of existing data and software: Many Web applications
build on existing data repositories and software components,
which were not created for Web applications originally. Content
modeling has to satisfy two potentially contradicting
objectives,i.e., it should cover the content requirements of the
Web application to the best possible extent, and it should include
existing data structures and software components.
Introduction
• Purpose: To model the information requirements of a Web application
– Diagramming the structural (i.e., information objects) & behavioral
aspects of the information.
– NOT concerned with navigation.
• Primary Models
– Class diagrams – enough for static applications.
– State machine diagrams – captures dynamic aspects
Content Structure Model

The Class diagram models a conference to be held on a number of
topics, and users who can sign in to the conference and submit their
papers. A paper is subject to a review by three reviewers. Notice the
invariant attached to the class “Paper”:it ensures that authors won’t be
able to review their own papers.
Content Behavior Model
The State m/c diag used to model the various states of a paper in the
reviewing system. It shows that a submitted paper will be assigned to
three reviews for review after the submission deadline has expired. If a
pre-set threshold value is reached ,the paper is accepted; otherwise, it
is rejected. In both cases the authors are notified via e-mail.
How to model the hypertext of a Web application
5.6 HYPERTEXT MODELING
The objective of hypertext modeling- also known as navigation
modeling- is to specify the navigability through the content of a Web
application,.i.e., the navigation paths available to the users. Hypertext
modeling generates a two-fold result: First it produces the hypertext
structure model,also known as navigation structure model which
defines the structure of hypertext,i.e., which classes of the structure
can be visited by navigation.Second, it refines the hypertext
structure model by access elements in the form of an access model.
Navigation Structure Model

In the reviewing system example hypertext views are required for the
following users:author,reviewer,and PC chair.The figure shows the PC
chair view. A PC chair can view all submitted papers. In addition ,the
PC chair can access the list of accepted or rejected papers, and the
reviewer profile.(which is in line UWE )
Introduction
• Purpose: To model the navigation paths available to users
• UWE Artifacts
– Hypertext Structure Model – navigating among classes
– Access Model – UML-compliant site map
• Focuses on the structure of the hypertext & access elements
• Use “<<navigation class>>” annotation to distinguish from content
classes
• Based on content models
Different Models… Different Links…

• HDM (Hypertext Design Model)specifies the following links
– Structural links connect elements of the same node, e.g., from a
review summary to the review details.
– Perspective linksput various views of anode in relation to each
other ,e.g., the PostScript and PDF versions of a paper.
– Application links put different nodes in relation to each other,
depending on the application,e.g., a link pointing to” best paper”
• WebML (Web Modeling Language) possible transport of info during

navigation.For eg it specifies the following links
– Contextual links carry context info ,eg.,the unique number of a
reviewer ,to navigate from one reviewer to the reviews he or she
created.
– Non-contextual links hve no associated context info, eg., links
pointing from a single review to the list of all reviews.
WML additionaly have the foll specifics
– Intra-page links are used when the source and the destination of a
link belong to the same page, eg., when a link allows the user to
directly navigate to the summary of a paper, which is displayed further
down on the page.
– Inter-page links are used when the source and destination are on
different pages, eg., when detailed info about the authors and their
papers are on different pages.
• Functional requirements of Web applications, the UWE defines the

following links:
–Navigation links are used to navigate between nodes ,e.g., links
between papers and their authors
–Process links point to the start node of a process, eg., to the
beginning of the review submission.
–External links point to a node not directly belonging to the application,
e.g., to the formatting guidelines established by the publisher of the
conference proceedings, which are not directly stored in the reviewing
system.
•OO-H(Object-Oriented Hypermedia) modeling method defines five
types of links
–I-links (internal links) point to nodes inside the boundaries of a given
navigational req e.g., internal links to review details of one of the
reviewers.
–T-links (traversal links) point to the nodes covering other navigational
req, e.g., from an author to his or her papers.
–R-link(req links)point to a start of a navigational path, e.g., to add a
new review.
–X-link(external link) point to external nodes, e.g., to external
formatting guidelines.
–S-links(service links) point (with their corresponding response links) to
services ,e.g., to an external search engine
Navigation Access Model

• Hypertext structure models describe navigation, but not orientation.
• Access models describe both through Navigation patterns, used to
consistently describe conventional elements.
– <<index>> (list of objects of the same type)
– <<menu>> (list of heterogeneous objects)
– <<guided-tour>> (sequential links)
– <<query>>
– This(UWE) shows the simplified access model of the PC chair’s
view specified in the hypertext structure model in our reviewing
system. Note the links default multiplicity is 1. The PC chair has
access to all papers, reviews, and users. To access a paper, a
unique number is used. Alternatively , the PC chair can search for
a paper by title.
How to model the look&feel of a Web application
5.7 PRESENTATION MODELING.
Introduction
• Purpose: To model the look & feel of the Web application at the page
level.
• The design should aim for simplicity and self explanation.
• Describes presentation structure:
– Composition & design of each page
– Identify recurring elements (headers/footers)
• Describes presentation behavior:
– Elements => Events
Levels of Presentation Models(on three hierarchical levels):

• Presentation Page – “root” element; equivalent to a page container.
• Presentation Unit
– A fragment of the page logically defined by grouping related
elements.
– Represents a hypertext model node
• Presentation Element
– A unit’s (node’s) informational components
– Text, images, buttons, fields
Presentation Structure Model

Shows two presentation pages(paper and author) of our reviewing
system.
Presentation Behavior Model

Behaviour aspects of the user interface,such as reviewer’s interaction
to navigate to the papers assigned to him or her for reviewing, can be
modeled by means of behavior diagrams, as shown in figure.In general
, a user’s interaction with the Web application does not only involve
the presentation level: it is also forwarded to the hypertext level and
the content level, depending on the type of interaction.
5.8 Customization Modeling
• aimed at explicitly representing context information, and the
adaptations derived from it
• customization modeling is intermixed with content, hypertext,
and presentation models
• Concepts
o user profile - preferences and characteristics of a user
o device profiles, location information, and transmission
bandwidth for mobile computing
How other model looks like?!

OVERVIEW OF
ODER MODELING METHODS
HERA
OOHDM
WebML

(or summary)
• Modeling is fundamental
– Helps development
– Support communication
• Model Driven Design and Development
– Automatic code generation of Web applications
• One model for each layer
– Content
– Navigation
– Presentation
• Different methods have different expressive power
Mandatory reading(Learning)
– Web Engineering
• Chapter 3
Self Learning
• Suggested
– First International Workshop on Web-Oriented SoftwareTechnology
• http://www.dsic.upv.es/~west/iwwost01/
– UML-based Web Engineering
• http://www.pst.informatik.uni-muenchen.de/projekte/uwe/index.html

Web Engineering Stud

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Web Engineering Stud

Uploaded by

Copyright:

Available Formats

WEB ENGINEERING

Prepared by :Priyanka Desai Page

Background of web engineering

Why do we need Web Engineering?

What is Web Engineering?

MOTIVATION OF WEB APPLICATION

Software engineering is defined as the application of science and

1.2 Categories of Web Applications

Interactive & Transactional

Collaborative & Social Web

The 4th Dimension: Evolution

Key Knowledge Areas

– Standards are important, especially for national initiatives and other

Why do we need Requirements?

Good Requirements Specifications

Functional Requirement Types

Non-Functional Requirement Types

2.3 Specifics in Web Engineering

2.4 Principles for RE of Web applications

2.5 Adapting RE to Web Application Development

How to interact with Stakeholders

Techniques for Elicitation & Negotiation

Challenges with Stakeholders

Challenges with Developers

How to “formalize” received inputs

II. Use-case specification

II. Use-case specification

IV. Site Map specification

Things to keep in mind

Standards or not Standards?

<p> & <br>

Block Level Elements

<tr> & <td>

<th> & <caption>

How to make your Web page good looking

– Applied to Only ONE Unique Element in a Document

style =“font-size: size | keyword | %;”

Visual Formatting Model

• margin-left | margin-right | margin-top | marginbottom:

• background-position: % | length | keyword

• list-style-position: inside | outside

• visibility: visible | hidden

Web Engineering (703512)

JavaScript in Web Pages

Language Features in This Class

Unusual Features of JavaScript

Of Data, Files, and Text

• Binary file formats are advantageous because it is easy for

• The disadvantage of text files is that adding other information—

A Brief History of Markup

I might create an XML file like the following:

Opening an XML File in Internet Explorer

What Are the Pieces That Make Up XML?

An XML Document Can Have Only One Root Element

Elements Must Obey XML Naming Conventions

XPath Data Model

The Document Object Model

How Does an XSLT Processor Work?

Running the Examples

Procedural versus Declarative Programming

The HTML page created by the transformation is shown in Figure

Why do we need modeling?