<?xml version="1.0" encoding="UTF-8"?>
<!-- $Id: web-fall07.xml 734 2007-11-09 02:02:16Z dret $ -->
<?xslidy counter-separator=":&#160;" ?>
<?xslidy counter-format="full" ?>
<?xslidy extension-file="html" ?>
<?xslidy extension-link="" ?>
<?xslidy img-path="img" ?>
<?xslidy link-author="http://dret.net/netdret/" ?>
<?xslidy link-contents="./" ?>
<?xslidy link-glossary="http://dret.net/glossary/" ?>
<?xslidy link-home="./" ?>
<?xslidy listing-class="listing" ?>
<?xslidy listing-path="src" ?>
<?xslidy outline-class="outline" ?>
<?xslidy outline-title="Outline" ?>
<?xslidy outlink-mark="a" ?>
<?xslidy outlink-style="class(outlink)" ?>
<?xslidy part-slide-count="all" ?>
<?xslidy part-slide-text=" [*]" ?>
<?xslidy layout="ischool" ?>
<?xslidy xslidy-prefix="xslidy" ?>
<xslidy xmlns="http://dret.net/xmlns/xslidy/1" xmlns:xslidy="http://dret.net/xmlns/xslidy/1">
    <title short="Web Architecture"><a href="./" title="Course Homepage">Web Architecture</a> (INFO 290-03)</title>
    <author short="E. Wilde"><a href="http://dret.net/netdret/" title="dret.net">Erik Wilde</a></author>
    <affiliation short="UC Berkeley ISchool"><a href="http://www.berkeley.edu/" title="University of California, Berkeley">UC Berkeley</a> <a href="http://ischool.berkeley.edu/" title="ISchool">School of Information</a></affiliation>
    <date>Fall 2007</date>
    <copyright>2007 Erik Wilde</copyright>
	<style type="text/css" src="xslidy-fall07.css"/>
	<index name="index.html">
		<category element="xml" class="xml"/>
		<category element="elem" class="xml elem"/>
		<category element="html" class="html"/>
		<category element="htmel" class="html elem"/>
		<category element="cssp" class="css"/>
		<category element="csss" class="css"/>
		<category element="css" class="css"/>
		<category element="xpathf" class="xpath"/>
		<category element="xpath" class="xpath"/>
		<category element="xslte" class="xslt elem"/>
		<category element="xslta" class="xslt"/>
		<category element="xslt" class="xslt"/>
		<category element="xsde" class="xsd elem"/>
		<category element="xsda" class="xsd"/>
		<category element="xsd" class="xsd"/>
		<category element="uri" class="uri"/>
		<category element="http" class="http"/>
		<category element="mime" class="mime"/>
		<category element="atom" class="atom"/>
	</index>
	<toc name="toc.html">
		<table rules="all" cellspacing="0" cellpadding="5" width="100%">
			<thead>
				<tr>
					<th valign="bottom">Date</th>
					<th valign="bottom">Subject</th>
					<th valign="bottom">Slides</th>
					<th valign="bottom">Required Reading</th>
					<th valign="bottom">Additional Resources</th>
				</tr>
			</thead>
			<tbody>
				<xslidy:for-each-presentation>
					<tr>
						<td align="right" valign="top"><xslidy:date/></td>
						<td valign="top"><b><xslidy:title/><span class="toggle">:</span></b> <span class="toggle"><span class="abstract"><xslidy:toc class="abstract"/></span></span></td>
						<td align="center"><xslidy:presentation-link title="Lecture Slides"><xslidy:title form="short"/></xslidy:presentation-link> <xslidy:slides>(*&#160;Slides)</xslidy:slides></td>
						<td align="center"><xslidy:toc class="reading"/></td>
						<td align="center"><xslidy:toc class="resources"/></td>
					</tr>
				</xslidy:for-each-presentation>
			</tbody>
		</table>
	</toc>
    <toc name="290-03.xml">
		<course xmlns="urn:publicid:IDN+www.sims.berkeley.edu:schema:syllabusapp:syllabus:200404:en" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:publicid:IDN+www.sims.berkeley.edu:schema:syllabusapp:syllabus:200404:en syllabus_schema.xsd">
			<generalInformation>
				<title>Web Architecture</title>
				<units>3</units>
				<website>http://dret.net/lectures/web-fall07/</website>
				<departmentListing>
					<name>SIMS</name>
					<code>INFO</code>
					<courseNumber>290-03</courseNumber>
				</departmentListing>
				<schedule>
					<year>2007</year>
					<semester>F</semester>
					<startDate>2007-08-28</startDate>
					<endDate>2007-12-06</endDate>
				</schedule>
				<teachingTeam>
					<teacher>
						<typeCode>Professor</typeCode>
						<initials>EW</initials>
						<name>
							<givenName>Erik</givenName>
							<familyName>Wilde</familyName>
						</name>
						<contact>
							<email>dret@berkeley.edu</email>
							<phone>
								<type>Office</type>
								<number>+1-510-6432253</number>
							</phone>
							<website>http://dret.net/netdret/</website>
						</contact>
					</teacher>
					<teacher>
						<typeCode>TA</typeCode>
						<initials>IP</initials>
						<name>
							<givenName>Igor</givenName>
							<familyName>Pesenson</familyName>
						</name>
						<contact>
							<email>igorp@ischool.berkeley.edu</email>
						</contact>
					</teacher>
				</teachingTeam>
				<gradingOptionCode>LG</gradingOptionCode>
				<description>
					<p>This course is a broad survey of Web-based publishing, defined here as any well-designed service for providing information using Web formats and protocols. It touches on strategy and project planning considerations, but emphasizes design, implementation, and delivery issues. Design topics include publishing process modeling and document workflows, content reuse, document formats, compound documents, internationalization and localization, and the associated questions of usability and accessibility. Implementation issues include URI design, Web server setup, and storage management, starting from the foundation (XML databases) and moving on to specialized content management systems. Delivery issues include cross-media publishing and syndication alternatives such as RSS and Atom.</p>
				</description>
			</generalInformation>
			<syllabus>
				<instructionFormatCode>LEC</instructionFormatCode>
				<dayPattern>
					<dayTime>
						<dayOfWeek>Tu</dayOfWeek>
						<timeSpan>
							<startTime>09:00:00</startTime>
							<endTime>10:30:00</endTime>
						</timeSpan>
					</dayTime>
				</dayPattern>
				<dayPattern>
					<dayTime>
						<dayOfWeek>Th</dayOfWeek>
						<timeSpan>
							<startTime>09:00:00</startTime>
							<endTime>10:30:00</endTime>
						</timeSpan>
					</dayTime>
				</dayPattern>
				<location>202 South Hall</location>
				<classes>
					<xslidy:for-each-presentation>
						<class>
							<title><xslidy:title/></title>
							<date><xslidy:date form="short"/></date>
							<xslidy:if-toc class="abstract"><description><xslidy:toc class="abstract"/></description></xslidy:if-toc>
							<xslidy:if-toc class="reading"><readingList><reading><requirement>Required</requirement><comment><xslidy:toc class="reading"/></comment></reading></readingList></xslidy:if-toc>
							<resourceList>
								<resource>
									<title>Lecture Notes</title>
									<url><xslidy:presentation-link element="" prefix="http://dret.net/lectures/web-fall07/"/></url>
								</resource>
								<xslidy:if-toc class="resources">
									<resource>
										<title>Additional Resources</title>
										<comment><xslidy:toc class="resources"/></comment>
									</resource>
								</xslidy:if-toc>
							</resourceList>
						</class>
					</xslidy:for-each-presentation>
				</classes>
			</syllabus>
			<updated>
				<updateDate>Fall 2007</updateDate>
				<updateBy>dret</updateBy>
			</updated>
		</course>
    </toc>
    <presentation id="intro">
        <title short="Introduction">Overview and Introduction</title>
        <date>2007-08-28</date>
        <toc class="reading"><a href="http://www.martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf" title='Martin Fowler, "Who Needs an Architect?," IEEE Software, vol. 20,  no. 5,  pp. 11-13,  Sept/Oct 2003'>Architecture?</a></toc>
        <toc class="abstract">This introductory lecture gives the motivation for the course, some information about the people involved and the organization of the course, a high-level overview of the course's topics, and an overview of the assignments which are an important part of the course program.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<slide>
			<title>What is Architecture?</title>
			<table width="95%">
				<tr>
					<td>
						<img style="width : 90% ; margin : 2% ; " src="map-newyork.png" title="New York City"/>
					</td>
					<td>
						<img style="width : 90% ; margin : 2% ; " src="map-luebeck.png" title="Lübeck"/>
					</td>
				</tr>
			</table>
		</slide>
		<slide>
			<title>What is an Architect?</title>
			<img style="float : right ; margin-right : 2em ; " src="gherkin.jpg" title="London Gherkin" href="http://www.fosterandpartners.com/Projects/1004/Default.aspx"/>
			<ul>
				<li><q>Star Architects</q> are not typical</li>
				<ul>
					<li>they sell brand names and deliver high profile results</li>
					<li>most architects are more modest and less visible</li>
				</ul>
				<li>Architects must understand how things work</li>
				<ul>
					<li>a reasonable understanding of the disciplines involved</li>
					<li>an excellent understanding of disciplines have to interact</li>
					<li>negotiating between specialists for a good overall design</li>
				</ul>
				<li>Architects are guides</li>
				<ul>
					<li>they provide guidance for going in the right direction</li>
					<li>they can tell why this direction is the right direction</li>
					<li>they can tell why a wrong direction is wrong</li>
				</ul>
			</ul>
		</slide>
		<slide>
			<title>How to become a Web Architect?</title>
			<ul>
				<li>Understand Web technologies and their dependencies</li>
				<ul>
					<li>no need to become an expert in all of the areas</li>
					<li>the important part is understanding the dependencies</li>
				</ul>
				<li>Understand how to compare application architectures</li>
				<ul>
					<li>there is no <q>best solution</q> for any given problem</li>
					<li>every solution must be evaluated in terms of <em>various constraints</em></li>
				</ul>
				<li>Next steps for your career in Web architecture</li>
				<ul>
					<li>understand how the <a href="../xml-fall07/" title='"XML Foundations" course fall 2007'>back-end plumbing (a.k.a. XML)</a> works in detail</li>
					<li>take a closer look at <a href="../services-spring08/" title='"Web-Based Services" course spring 2008'>back-end architectures</a></li>
					<li>take a closer look at <a href="../publishing-spring08/" title='"Web-Based Publishing" course spring 2008'>delivery architectures</a></li>
					<li>get involved in <a href="http://isd.ischool.berkeley.edu/project/" title="ISD Clinic project overview">real-world projects</a> in the <a href="http://isd.ischool.berkeley.edu/about/clinic" title="ISD Clinic project overview">ISD Clinic</a></li>
				</ul>
			</ul>
		</slide>
		<slide>
			<title>Course Setup</title>
			<ul>
				<li>Broad overview of core Web technologies</li>
				<ul>
					<li>this is not a Web design or Web programming course</li>
				</ul>
				<li>Assignments working with various Web technologies</li>
				<ul>
					<li>how to setup and configure a Web server</li>
					<li>how to deliver client-specific content</li>
					<li>how to design client-specific styles</li>
					<li>using Ajax for creating more dynamic Web pages</li>
					<li>repurposing existing content for syndication</li>
				</ul>
				<li>Final project looking at a real-world case study</li>
				<ul>
					<li>apply a Web architecture view o a Web application architecture</li>
					<li>come up with an <link href="swot">analysis of the strengths, weaknesses, opportunities, and threats</link></li>
				</ul>
			</ul>
		</slide>
		<part>
			<title>Motivation</title>
			<slide>
				<title>Closed World Assumption</title>
				<blockquote>If the only tool you have is a hammer, you tend to see every problem as a nail.</blockquote>
				<p class="quotenote"><a href="http://en.wikipedia.org/wiki/Abraham_Maslow">Abraham Maslow</a></p>
				<ul>
					<li>People, and thus content creators, typically are lazy</li>
					<ul>
						<li>developing content and code for diverse users and clients is hard</li>
						<li>by making assumptions, this job can become considerably easier</li>
					</ul>
					<li>Tools often hide complexity and/or take away freedom</li>
					<ul>
						<li>they are good if tool users <em>know what they are doing</em></li>
						<li>tool users should <em>know alternatives and when to switch tools</em></li>
					</ul>
					<li>Tool makers provide support for lazy people</li>
					<ul>
						<li>built-in simplifications of the tool's target technology</li>
						<li>pre-packaged excuses why it is appropriate to use the tool</li>
					</ul>
				</ul>
			</slide>
			<part>
				<title>Bad Content</title>
				<slide>
					<title>Poorly Equipped Developers</title>
					<img style="height : 75% ; margin : 2% ; " src="mercedes.png" href="http://www.mbusa.com/"/>
				</slide>
				<slide>
					<title>Popular Screen Resolutions</title>
					<img style="width : 90% ; margin : 2% ; " src="resolutions.png" title="dret.net Statistics 2006"/>
				</slide>
			</part>
			<part>
				<title>Bad Systems</title>
				<slide>
					<title>Your Tax $ @ Work</title>
					<ul>
						<li><a href="http://www.grants.gov/applicants/apply_for_grants.jsp">How to apply for NSF grants</a></li>
						<li>Over $400 billion in grants each year</li>
						<li><em>PureEdge</em> is <em>required</em> as the technology to fill out grant forms</li>
							<ul>
								<li><a href="http://www-306.ibm.com/software/swnews/swnews.nsf/n/nhan6eerne">acquired by IBM</a> and now called <em href="http://www-142.ibm.com/software/workplace/products/product5.nsf/wdocs/formshome">IBM Workplace Forms</em></li>
							</ul>
						<li>All of this probably looked nice for the final demo …</li>
						<li>Web forms do not provide all the features required by the specification</li>
						<ul>
							<li>offline editing of applications is not possible, Web forms work online only</li>
							<li>there is no built-in signing of form contents, but there are technologies for it</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Version 1: Go IE or Go Home</title>
					<ul>
						<li>Well, but not if you are using Vista …</li>
						<li>PureEdge is an IE plug-in for filling out forms online and offline</li>
						<ul>
							<li>plug-ins are specific for the browser for which they are developed</li>
							<li>plug-ins are specific for the OS on which they run</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Version 2: Buy a Virtual Computer</title>
					<ul>
						<li>Government authorities are (usually) concerned about accessibility</li>
						<ul>
							<li>restricting $400 billion of grant money to IE users only seems a bit restrictive</li>
							<li>is there a <em>reasonable argument</em> to be made for this restriction</li>
						</ul>
						<li>Grants.gov recommended to get a virtual PC to access the portal</li>
						<ul>
							<li>users have to buy virtual PC software</li>
							<li>users have to buy Windows to run on the virtual PC</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Version 3: Use a Virtual Computer</title>
					<ul>
						<li>Grants.gov set up a <em>Citrix server</em> for grant applicants</li>
						<ul>
							<li>Citrix server licenses are not cheap to buy</li>
							<li>applicants still have to install the Citrix client (which is free)</li>
							<li>running a Citrix server farm is pretty expensive</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Version 4: Crash your Computer</title>
					<ul>
						<li>After some time, <a href="http://www.grants.gov/resources/download_software.jsp#pureedgeviewer">PureEdge for Mac was released</a>, features include:</li>						
						<ul>
							<li><q cite="http://www.grants.gov/resources/download_software.jsp#pureedgeviewer">occasional crashes and subsequent loss of any unsaved data</q></li>
							<li><q cite="http://www.grants.gov/resources/download_software.jsp#pureedgeviewer">inability to run on Mac OS version prior to 10.4.6</q></li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Classical Lock-In</title>
					<ul>
						<li>Companies usually sell <em>products</em>, not just <em>solutions</em></li>
						<li>Lock-in happens quickly and is very hard to escape from later</li>
						<li>Lock-in usually carries a pretty high price tag</li>
						<li>Lock-in solutions can be good, but it is a very important decision</li>
						<li>Standards-based solutions may lack some sophistication</li>
						<ul>
							<li>but very often they may still be good enough to solve a problem</li>
							<li>being able to change the platform easily is a very valuable asset</li>
						</ul>
					</ul>
				</slide>
			</part>
			<part>
				<title>Bad Planning</title>
				<slide>
					<title>Tax on Taxes</title>
					<img style="height : 60% ; padding : 0 4% 0 4% ; float : left ; " src="tax-filing-statistics.jpg" title="Tax E-Filing Statistics" href="http://www.nytimes.com/2007/04/23/technology/23intuit.html"/>
					<ul>
						<li>The I.R.S. perspective</li>
						<ul>
							<li>electronic filing saves money and should be encouraged</li>
							<li>processing a paper version: $2.65</li>
							<li>processing an electronic submission: $0.29</li>
						</ul>
						<li>The company perspective</li>
						<ul>
							<li>have a <q>monopoly</q> for 2005-2009</li>
							<li>taxpayers paid $1.01 billion for submission fees</li>
							<li>the servers could not handle the load</li>
						</ul>
						<li>The taxpayer perspective</li>
						<ul>
							<li>IRS saves money, but taxpayers are charged</li>
							<li>electronic filing must go through a company</li>
						</ul>
					</ul>
				</slide>
			</part>
		</part>
		<part>
			<title>Varia</title>
			<slide>
				<title>About Me</title>
				<ul>
					<li>Computer Science at <a href="http://www.tu-berlin.de/eng/">Technical University of Berlin (TUB)</a> (88-91)</li>
					<li>Ph.D. at <a href="http://www.ethz.ch/index_EN">ETH Zürich</a> (92-97)</li>
					<li>Post-Doc at <a href="http://www.icsi.berkeley.edu/">ICSI, Berkeley</a> (97/98)</li>
					<ul>
						<li>book on <q><a href="http://dret.net/netdret/publications#wil98">Technical Foundations of the World Wide Web</a></q>
						</li>
					</ul>
					<li>Various activities back in Switzerland (98-06)</li>
					<ul>
						<li>teaching at <a href="http://www.ethz.ch/index_EN">ETH Zürich</a> and <a href="http://www.fhnw.ch/">FHNW</a></li>
						<li>working as independent consultant (training, courses, consulting)</li>
						<li>research in <a href="http://dret.net/projects/">various XML-related areas</a></li>
					</ul>
					<li>Visiting Assistant Professor at the <a href="http://ischool.berkeley.edu/">School of Information</a> (since fall 2006)</li>
					<ul>
						<li>technical director of the <a href="http://isd.ischool.berkeley.edu/">Information and Service Design (ISD) program</a></li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>About this Course</title>
				<ul>
					<li>Course Web page: <code><a href="./">http://dret.net/lectures/web-fall07/</a></code></li>
					<li>Course mailing list: subscribe at <code><a href="mailto:majordomo@ischool.berkeley.edu">majordomo@ischool.berkeley.edu</a></code></li>
					<ul>
						<li>no subject (leave blank)</li>
						<li>body of message: <code>subscribe i290-3</code></li>
					</ul>
					<li>Letter grade based on assignments, mid-term exam, and final project</li>
				</ul>
			</slide>
			<slide>
				<title>About these Slides</title>
					<ul>
						<li>Generated from <a href="http://dret.net/projects/xslidy/">XSLidy</a> <a href="./web-fall07.xml">XML</a></li>
						<li>Designed for online presentation and use (lots of links!)</li>
						<ul>
							<li>for printing, use <q>a</q> (all slides), and then <q>s</q> (smaller font) a couple of times</li>
						</ul>
						<li>A good real-world example for Web-based publishing</li>
						<ul>
							<li>Slidy is useful, but there is no support for structures and hyperlinking</li>
							<li>XSLidy adds these features by adding an XSLT transformation</li>
							<li>XSLidy is useful, but there is no interface (XML editing only)</li>
						</ul>
					</ul>
			</slide>
			<slide>
				<title>Additional Resources</title>
				<ul>
					<li>My <a href="http://dret.net/glossary/">Online Glossary at <code>http://dret.net/glossary/</code></a></li>
					<ul>
						<li>suggestions, updates, corrections are very welcome (really!)</li>
						<li>another exercise in how to use XML and XSLT for information management</li>
					</ul>
					<li>My <a href="http://dret.net/biblio/">bibliography at <code>http://dret.net/biblio/</code></a></li>
					<ul>
						<li>suggestions, updates, corrections are very welcome (really!)</li>
						<li>produced by an XML-centric system for managing bibliography data</li>
					</ul>
					<li>The <a href="http://www.w3.org/"><em>World Wide Web Consortium (W3C)</em></a></li>
					<ul>
						<li>headed by <em href="http://www.w3.org/People/Berners-Lee/">Tim-Berners Lee</em>, inventor of the Web (with <a href="http://en.wikipedia.org/wiki/Robert_Cailliau">Robert Cailliau</a>)</li>
					</ul>
					<li>The <a href="http://www.ietf.org/"><em>Internet Engineering Task Force (IETF)</em></a></li>
					<ul>
						<li>mainly Internet standards, but also responsible for URIs and HTTP</li>
					</ul>
				</ul>
			</slide>
		</part>
    </presentation>
    <presentation id="architecture">
        <title short="Web Architecture">Architecture of the World Wide Web</title>
        <date>2007-08-30</date>
        <toc class="reading"><a href="http://www.w3.org/TR/webarch/summary.html" title="W3C Web Architecture Specification Summary">Architecture Summary</a></toc>
        <toc class="resources"><a href="http://www.w3.org/TR/webarch/" title="W3C Web Architecture Specification">Architecture</a></toc>
        <toc class="abstract">The Web's architecture has very simple principles revolving around the ideas of <em>placing a heavy emphasis on a consistent and global identification mechanism for resources</em>, a <em>standardized way of how resource representations can be retrieved</em>, and a <em>standardized way of how resource representations should be usable by using standardized media types</em>. This lecture presents an overview of these architectural principles and illustrates them with using blogs as an example of Web-based applications.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<slide>
			<title>Today's Reading</title>
			<blockquote><a href="http://www.w3.org/TR/webarch/summary.html">Summary</a> of <a href="http://www.w3.org/TR/webarch/">Ian Jacobs, Norman Walsh, <q>Architecture of the World Wide Web, Volume One</q>, World Wide Web Consortium, Recommendation REC-webarch-20041215, December 2004</a></blockquote>
			<ul>
				<li>Examples (or counter-examples) for the following principles, practices, and constraints:</li>
				<ul>
					<li>URIs identify a single resource (versioning, aliases)</li>
					<li>URI opacity (assuming a specific resource representation)</li>
					<li>Available representations (XML namespaces as really bad example)</li>
					<li>Hypertext links (resource representations should be good Web citizens)</li>
					<li>Orthogonality (identification, interaction, and representation are orthogonal)</li>
				</ul>
			</ul>
		</slide>
		<part>
			<title>Parsimony</title>
			<slide>
				<title>Keep It Simple</title>
				<ul>
					<li>Loose coupling vs. tight coupling</li>
					<ul>
						<li>fewer requirements for cooperation mean fewer potential sources of problems</li>
						<li>taking independent developments into consideration (graceful degradation)</li>
					</ul>
					<li>Parsimony may conflict with optimization</li>
					<ul>
						<li>a fully backlinked Web would be a very different hypermedia system</li>
						<li>modifying resources would be expensive and require considerable efforts</li>
						<li>an uncontrolled Web allows failure and innovative development</li>
					</ul>
					<li>Programming Languages vs. Frameworks</li>
					<ul>
						<li>programming languages are very simple and very powerful</li>
						<li>frameworks are more complex and have some choices built into them</li>
						<li>both can be used to build good systems</li>
						<li>framework applications are more likely to not do really innovative things</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Web Design as System Design</title>
				<blockquote>There are two ways of constructing a software design: One way is to make it so simple that there are <em>obviously</em> no deficiencies, and the other way is to make it so complicated that there are no <em>obvious</em> deficiencies. The first method is far more difficult.</blockquote>
				<p class="quotenote"><a href="http://en.wikipedia.org/wiki/Charles_Antony_Richard_Hoare">C. A. R. Hoare</a>, <a href="http://dret.net/biblio/reference/hoa81"><q>The Emperor's Old Clothes</q>, 1980 Turing Award Lecture</a></p>
				<ul>
					<li>Web: URI + HTTP + HTML ( + XML)</li>
					<li>OASIS: <a href="http://www.infoworld.com/article/07/08/09/sca-oasis_1.html">Six SOA simplification committees</a> for <a href="http://en.wikipedia.org/wiki/List_of_Web_service_specifications">about 60 WS-* specs</a></li>
				</ul>
			</slide>
			<slide>
				<title>Technology Blinders</title>
				<ul>
					<li>Web architecture is an additional set of constraints</li>
					<ul>
						<li>it is not a very complicated set of constraints</li>
						<li>but it still makes life more complicated than in an unconstrained world</li>
						<li>it may require a major redesign of an application</li>
					</ul>
					<li>Technology providers sometimes ignore Web architecture</li>
					<ul>
						<li>multimedia presentation concepts are often disconnected from the Web</li>
						<li>hypermedia researchers often regard the Web as inferior (or not as hypermedia at all)</li>
						<li>questions of client capabilities are often ignored (or brushed aside using statistics)</li>
					</ul>
					<li>Integration vs. Transport</li>
					<ul>
						<li>integrating into the Web requires application to conform to Web architecture</li>
						<li>sitting on top of the Web just requires to use HTTP for data transfer</li>
						<li>many <q>Web Technologies</q> are <em>not</em> integrated into the Web</li>
						<li>many <q>Web Applications</q> are <em>not</em> integrated into the Web</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part>
			<title>Principles</title>
			<slide>
				<title>Identification</title>
				<ul>
					<li>Everything should be identified in a uniform way</li>
					<li>Identification and access methods evolve over time</li>
					<ul>
						<li><uri>sms:</uri> and <uri>callto:</uri> did not exist when the Web was created</li>
					</ul>
					<li>Identification and access support evolve over time</li>
					<ul>
						<li><uri>tel:</uri> now can be supported by an increasing number of clients</li>
					</ul>
					<li>The Web is one huge proof for the power of <em>network effects</em></li>
					<ul>
						<li>it also is a lesson for many who did not take it seriously and failed</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Interaction</title>
				<ul>
					<li>Many URI schemes are named after protocols</li>
					<ul>
						<li><uri>http:</uri> can be accessed using the <em>Hypertext Transfer Protocol (HTTP)</em></li>
						<li><uri>ftp:</uri> can be accessed using the <em>File Transfer Protocol (FTP)</em></li>
						<li><uri>mailto:</uri> sends electronic mail using the <em>Simple Mail Transfer Protocol (SMTP)</em></li>
					</ul>
					<li>Some URI schemes do not really imply a protocol</li>
					<ul>
						<li><uri>mailto:</uri> sends electronic mail using the <em>Simple Mail Transfer Protocol (SMTP)</em></li>
						<li><uri>mailto:</uri> may use any other appropriate technology for sending email</li>
					</ul>
					<li>Some URI schemes have no protocol for dereferencing resources</li>
					<ul>
						<li><uri>urn:</uri> URIs are abstract names from some namespace</li>
						<li><uri>urn:ietf:rfc:2648</uri> identifies an IETF standard and not some specific copy</li>
						<li><uri href="http://maps.google.com/maps?ll=27.988056,86.925278&amp;spn=0.1,0.1&amp;q=27.988056,86.925278+(Mount_Everest)">geo:27.988056,86.925278</uri> identifies a physical resource (accessing it is really hard)</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Data Formats</title>
				<ul>
					<li>Agreement on the interpretation of resource representations</li>
					<li>HTML was the first standardized data format on the Web</li>
					<ul>
						<li>CSS and XML have become successful formats as well</li>
					</ul>
					<li>Some data formats are <em>de-facto standards</em> as Web formats</li>
					<ul>
						<li>GIF and JPEG for images and PNG as the successor of GIF</li>
					</ul>
					<li>Some formats are less integrated but still widely used</li>
					<ul>
						<li>PDF for paginated documents</li>
					</ul>
					<li>Some formats have become replacements for missing standards</li>
					<ul>
						<li>Flash for audio and video because no single format was sufficiently successful</li>
					</ul>
					<li>Some formats were intended to become standards but failed</li>
					<ul>
						<li>SVG for vector graphics</li>
						<li>SMIL for multimedia presentations</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Identifier, Resource, and Representation</title>
				<img style="height : 75% ; margin : 2% ; " src="uri-res-rep.png" href="http://www.w3.org/TR/webarch/#p21"/>
			</slide>
		</part>
		<part>
			<title>Constraints and Good Practices</title>
			<slide>
				<title>Constraints</title>
				<ul>
					<li>Some things on the Web can be inconsistent</li>
					<ul>
						<li>guaranteeing consistency by design can lead to tight coupling</li>
						<li>well-defined ways of handling inconsistencies are better scalable</li>
					</ul>
					<li>Some things on the Web are not perfect</li>
					<ul>
						<li>technologies being used in ways not anticipated (XML, XML Namespaces)</li>
						<li>company goals vs. the greater good (<a href="http://en.wikipedia.org/wiki/Browser_wars">browser war</a>)</li>
					</ul>
					<li><q>The ideal Web</q> vs. <q>the real Web</q></li>
					<ul>
						<li>dealing with a given landscape can introduce additional constraints</li>
						<li>handling these constraints should not violate the general principles</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Good Practices</title>
				<ul>
					<li>Design for openness and extensibility is a key factor</li>
					<ul>
						<li>design for and support evolution and extension and reuse</li>
						<li>try to be a good Web citizen by embracing integration</li>
					</ul>
					<li>Design with the Web in mind</li>
					<ul>
						<li>use Web standards where appropriate (URIs for identification)</li>
						<li>even intranet apps typically evolve and should be designed for the Web</li>
					</ul>
					<li>Make content visible, accessible, usable, reusable</li>
					<ul>
						<li>URI design guidelines should be defined and followed</li>
						<li>think about aggregation and granularity and access to resources</li>
						<li>use well-defined and well-documented XML for B2B scenarios</li>
						<li>reuse existing vocabularies or vocabulary parts whenever possible</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part id="dretblog">
			<title>Blogs as Web Apps</title>
			<slide>
				<title>Blog in XML</title>
				<listing src="dretblog.xml"/>
			</slide>
			<slide>
				<title>Support URI Guessing (Year Index)</title>
				<listing src="dretblog2html.xsl" line="43-56"/>
			</slide>
			<slide>
				<title>Support URI Guessing (Month Index)</title>
				<listing src="dretblog2html.xsl" line="57-73"/>
			</slide>
			<slide>
				<title>Support URI Guessing (Day Index)</title>
				<listing src="dretblog2html.xsl" line="74-92"/>
			</slide>
			<slide>
				<title>Support Spontaneous Navigation</title>
				<listing src="dretblog2html.xsl" line="26-39"/>
			</slide>
			<slide>
				<title>Publishing as Atom Feed</title>
				<listing src="dretblog2atom.xsl" line="4-27"/>
			</slide>
			<slide>
				<title>Blog as Atom Feed</title>
				<listing src="dretblog.atom" line="2-26"/>
			</slide>
		</part>
		<part>
			<title>Conclusions</title>
			<slide>
				<title>Web Architecture Essentials</title>
				<ul>
					<li>Principles (violating these causes architectural problems)</li>
					<li>Constraints (disregarding these causes technical problems)</li>
					<li>Good Practices (ignoring these causes user problems)</li>
				</ul>
			</slide>
		</part>
    </presentation>
    <presentation id="internet">
        <title short="Internet">Internet Foundations</title>
        <date>2007-09-04</date>
        <toc class="reading"><a href="http://www.zakon.org/robert/internet/timeline/" title="Hobbes' Internet Timeline">Timeline</a></toc>
        <toc class="resources"><a href="http://en.wikipedia.org/wiki/Category:Internet_architecture" title="Wikipedia: Internet Architecture">Internet Architecture</a></toc>
        <toc class="abstract">The Internet is the technical infrastructure on top of which the Web is built. Some of the services provided by the Internet are essential for the Web, most importantly the naming service and the data transfer service. The <em>Domain Name System (DNS)</em> provides the human-readable names for computers, which can then be used in the addresses of Web servers and ultimately Web pages. The <em>Transmission Control Protocol (TCP)</em> provides the reliable data transfer service between Web Servers and Web Browsers, building on the very robust <em>Internet Protocol (IP)</em>.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
        <part id="networks">
			<title>Computer Networks</title>
			<slide>
				<title>Network History</title>
				<ul>
					<li>First regarded as a convenient workaround for floppy disks</li>
					<ul>
						<li><q>real computer scientists write compilers</q></li>
						<li>the value of computer networks depends on their size</li>
					</ul>
					<li>Early networking solutions were vendor-specific islands</li>
					<ul>
						<li>DECnet for <em>Digital Equipment Corporation (DEC)</em> customers</li>
						<li>XNS for <em>Xerox</em> customers</li>
						<li>SNA for <em>IBM</em> customers</li>
						<li>transmitting data between these networks was very cumbersome</li>
					</ul>
					<li>Bridging networks transparently became increasingly important</li>
					<ul>
						<li>more computers and networks increase the benefit of interconnections</li>
						<li>layering being used for internetworks, not only for networks</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Networks vs. Internetworks</title>
				<ul>
					<li>Specific networks use specific abstractions</li>
					<ul>
						<li>how to address nodes (computers, phones, PDAs, RFID tags)</li>
						<li>how to address applications on these nodes</li>
						<li>how to transmit data to these applications</li>
					</ul>
					<li>Internetworks provide a network-independent abstraction</li>
					<ul>
						<li>nodes are addressed uniformly (IP addresses)</li>
						<li>applications are identified uniformly (ports)</li>
						<li>data transmission uses one set of protocols (TCP/UDP)</li>
					</ul>
				</ul>
			</slide>
			<part id="protocols">
				<title>Networking Protocols</title>
				<slide>
					<title>Internet vs. ISO/OSI</title>
					<ul>
						<li>Global network emerges by the end of the 80's</li>
						<ul>
							<li>some kind of internetworking protocols were required</li>
							<li>ARPANET had been running since the late 60's (1965: Berkeley-MIT)</li>
						</ul>
						<li><link href="osi"/> was a new specification</li>
						<ul>
							<li>the idea was to build something new</li>
							<li>OSI was specified rather than developed and tested</li>
						</ul>
						<li>For some time, it was unclear what the <q>global internetwork</q> would be based on</li>
						<ul>
							<li>Internet protocols were already established and running</li>
							<li>OSI promised a fresh start with <q>bigger is better</q> protocols</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Internet</title>
					<ul>
						<li>Very early start and a lot of experience</li>
						<ul>
							<li>pragmatic and evolutionary approach</li>
							<li><q>if it's not broken, don't fix it</q></li>
						</ul>
						<li>Standardization by independent technical experts</li>
						<ul>
							<li>avoids the <q>designed by committee</q> effect of consortiums</li>
							<li>conservative and concentrating on stability</li>
							<li>implementations are required to prove technical feasibility</li>
							<li>simplicity whenever possible</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Internet Principles</title>
					<blockquote>Be liberal in what you accept, and conservative in what you send.</blockquote>
					<p class="quotenote"><a href="http://www.postel.org/postel.html">Jon Postel</a>, <a href="http://dret.net/rfc-index/reference/RFC1122">RFC 1122</a></p>
					<blockquote>Whenever possible, communications protocol operations should be defined to occur at the end-points of a communications system, or as close as possible to the resource being controlled.</blockquote>
					<p class="quotenote"><a href="http://dret.net/biblio/reference/sal84">J. Saltzer, D. Reed, D. Clark, <q>End-to-end Arguments in System Design</q></a></p>
				</slide>
				<slide id="osi">
					<title short="ISO/OSI">ISO/OSI (Open Systems Interconnection)</title>
					<ul>
						<li>Designed and specified in the 80's</li>
						<ul>
							<li>a <q>start-from-scratch</q> approach to an internetworking protocol suite</li>
							<li>many research contributions, many research publications</li>
							<li>great for teaching principles of communications systems layers</li>
						</ul>
						<li>Problems with complexity and interoperability</li>
						<ul>
							<li>some OSI protocols were never fully implemented</li>
							<li>because of many optional features, interoperability was a problem</li>
						</ul>
						<li>Some of OSI's better ideas had to be retrofitted to the Internet</li>
						<ul>
							<li><em>session management</em> (Layer 5) now is <link href="cookie">HTTP cookies</link></li>
							<li><em>data representation</em> (Layer 6) now is <em>XML</em></li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>OSI vs. Internet</title>
					<img style="height : 70% ; margin : 2% ; " src="osi-vs-internet.gif"/>
				</slide>
				<slide>
					<title>Internet Protocols</title>
					<img style="width : 90% ; margin : 2% ; " src="internet-layers.gif"/>
				</slide>
			</part>
			<part id="ip">
				<title short="IP">Internet Protocol (IP)</title>
				<slide>
					<title>IP Features</title>
					<ul>
						<li>End-to-end data transfer (IP addresses)</li>
						<li>Hiding lower-level heterogeneity</li>
						<li>Connection-less (each packet routed individually)</li>
						<li>Unreliable (packets may be lost or duplicated)</li>
					</ul>
				</slide>
				<slide id="ip-address">
					<title>IP Address</title>
					<ul>
						<li>IP identifies nodes by an IP address</li>
						<li>IP addresses are globally unique (<a href="http://api.hostip.info/get_html.php?position=true">and can be geocoded</a>)</li>
						<li>IP uses 4 bytes for addresses (e.g., <code>128.32.226.29</code>)</li>
						<ul>
							<li>maximum number of addresses: 2<sup>32</sup> = 4 billion</li>
							<li>IPv6	extends the address format to 16 bytes (2<sup>128</sup> addresses)</li>
						</ul>
						<li>IP addresses are well-organized</li>
						<ul>
							<li>important for routing (i.e., sending packets to the target host)</li>
							<li>not ideally suited for mobile or ad-hoc networks</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>IP Address Classes</title>
					<img style="width : 90% ; margin : 2% ; " src="ip-address.jpg"/>
				</slide>
			</part>
			<part id="tcp">
				<title short="TCP">Transmission Control Protocol (TCP)</title>
				<slide>
					<title>TCP Features</title>
					<ul>
						<li>Flow-controlled (avoiding congestion)</li>
						<li>Reliable (no data lost or duplicated)</li>
						<li>Connection-oriented</li>
						<li>Application addressing</li>
					</ul>
				</slide>
				<slide>
					<title>Reliable Connections</title>
					<ul>
						<li>IP may drop or duplicate packets</li>
						<ul>
							<li>TCP adds serial numbers in data packets</li>
							<li>if problems are detected, TCP recovers automatically</li>
						</ul>
						<li>TCP avoids network congestion and system overload</li>
						<ul>
							<li><em>slow start</em> avoid flooding receivers with data they cannot process</li>
							<li><em>fast retransmit</em> for avoiding timeouts when losing data</li>
							<li>a <em>sliding window</em> for controlling the amount of outstanding packets</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>TCP Window</title>
					<img style="height : 70% ; margin : 2% ; " src="tcp-window.png"/>
				</slide>
			</part>
			<part id="dns">
				<title short="DNS">Domain Name System (DNS)</title>
				<slide>
					<title>Naming vs. Addressing</title>
					<ul>
						<li>IP addresses depend on network topology and organization</li>
						<ul>
							<li>reorganizing a network may change all IP addresses</li>
							<li>identifying important hosts should not be address-based</li>
						</ul>
						<li>Names are supposed to be more stable than addresses</li>
						<ul>
							<li>a name is an abstract identification of something</li>
							<li>names can be used to obtain more information</li>
						</ul>
						<li>Network services should use names instead of addresses</li>
						<ul>
							<li>before using the service, a mapping has to be performed</li>
							<li>the <em>Domain Name System (DNS)</em> is providing this service</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>DNS Properties</title>
					<ul>
						<li>DNS has a bootstrap problem</li>
						<ul>
							<li>DNS provides a service and should thus be identified by a name</li>
							<li>for resolving names into addresses, the DNS service is required</li>
						</ul>
						<li>DNS configuration is part of basic Internet configuration</li>
						<ul>
							<li><em>Dynamic Host Configuration Protocol (DHCP)</em> provides <link href="ip-address"/>, netmask, gateway, and DNS server address</li>
						</ul>
						<li>DNS names are hierarchically structured</li>
						<ul>
							<li><code>ischool.berkeley.edu</code>, <code>edu</code> is the <em>Top-Level Domain (TLD)</em></li>
							<li>TLDs are either <em>generic (gTLD)</em> or <em>country code (ccTLD)</em></li>
							<li>subdomains are federated (e.g., <code>edu</code>, <code>us</code>, <code>uk</code>, <code>tv</code>)</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Names Matter</title>
					<ul>
						<li>Names are not unique and namespaces are finite</li>
						<ul>
							<li>name disputes arise which were irrelevant before the Web</li>
							<li><q>cybersquatting</q> as a popular way to make money</li>
						</ul>
						<li>Names can be worth a lot of money</li>
						<ul>
							<li><code>business.com</code> was sold for $7.5 million</li>
						</ul>
						<li>Name inflation can be used to generate money</li>
						<ul>
							<li><code>aero</code>, <code>biz</code>, <code>coop</code>, <code>info</code>, <code>jobs</code>, <code>mobi</code>, <code>museum</code>, <code>name</code>, <code>pro</code>, <code>travel</code></li>
						</ul>
						<li>Names can have political significance</li>
						<ul>
							<li>ccTLDs are assigned based on the UNO's idea of what a country is</li>
						</ul>
						<li>Names can have symbolic significance</li>
						<ul>
							<li>Catalonia managed to get a domain of its own (<code>cat</code>)</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Domain Name Space</title>
					<img style="height : 70% ; margin : 2% ; " src="dns-namespace.png"/>
				</slide>
				<slide>
					<title>Using DNS</title>
					<ul>
						<li>DNS is used by virtually all Internet applications</li>
						<ul>
							<li>names are more stable than addresses</li>
						</ul>
						<li>E-mail has some dedicated features built into DNS</li>
						<ul>
							<li>special entries (<code>MX</code> records) identify the e-mail server for a domain</li>
							<li>fallback entries help dealing with failing e-mail servers</li>
						</ul>
						<li>most URIs are based on DNS names</li>
						<ul>
							<li><code>http://ischool.berkeley.edu/</code> identifies the access protocol and the host</li>
							<li>the browser first performs a DNS lookup</li>
							<li>a TCP connection is then established to the address returned by the DNS</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>DNS Request Processing</title>
					<img style="width : 94% ; margin : 2% ; " src="dns-request.png"/>
				</slide>
			</part>
			<part id="other-protocols">
				<title>Other Internet Protocols</title>
				<slide id="udp">
					<title short="UDP">User Datagram Protocol (UDP)</title>
					<ul>
						<li>Transport protocol based on <link href="ip"/>, just like <link href="tcp"/></li>
						<ul>
							<li>very thin protocol, adds little features to IP</li>
							<li>provides application addressing</li>
						</ul>
						<li>UDP is unreliable and connection-less</li>
						<ul>
							<li>ideal for fast streaming media (delay is critical, lost packets are tolerable)</li>
							<li>acceptable for one-packet applications (lightweight and fast)</li>
							<li>not acceptable for reliable data transfer</li>
						</ul>
					</ul>
				</slide>
				<slide id="arp">
					<title short="ARP">Address Resolution Protocol (ARP)</title>
					<ul>
						<li>How to find an Internet host</li>
						<ul>
							<li>hosts are configured (manually or by using DHCP)</li>
							<li>there is no externally controlled registry of available hosts</li>
						</ul>
						<li><link href="ip"/> routing finds the network, but what about the host?</li>
						<ul>
							<li>the sender broadcasts a request with the <link href="ip-address"/></li>
							<li>if there is such a host, it responds with its physical address</li>
							<li>the sender can now send the IP packet to the physical address</li>
						</ul>
					</ul>
				</slide>
			</part>
        </part>
        <part>
			<title>Conclusions</title>
			<slide>
				<title>Internet Technologies</title>
				<ul>
					<li><q href="http://www.youtube.com/watch?v=f99PcP0aFNE">The Internet is a series of tubes</q></li>
					<li>The Internet can connect various underlying networks</li>
					<li><link href="ip"/> transmits data between Internet hosts</li>
					<li><link href="tcp"/> provides reliable data transfer for applications</li>
					<li><link href="dns"/> allows to use names rather than addresses</li>
				</ul>
			</slide>
			<slide>
				<title>Web Technologies</title>
				<ul>
					<li>The Internet is a communications infrastructure</li>
					<li>The Web is an Internet-based distributed hypermedia system</li>
					<li>In theory, the Web could run on any network infrastructure</li>
					<li>The Web's core network technology is <link href="http">HTTP</link></li>
					<li>HTTP uses TCP and DNS for transmitting Web content</li>
				</ul>
			</slide>
        </part>
    </presentation>
    <presentation id="foundations">
        <title short="Foundations">Web Foundations (URI &amp; HTTP)</title>
        <date>2007-09-06</date>
        <toc class="reading"><a href="http://www.w3.org/Provider/Style/URI" title="Cool URIs don't change">Cool URIs</a></toc>
        <toc class="resources"><a href="http://www.w3.org/International/questions/qa-apache-lang-neg" title="Apache Language Negotiation Setup">Language Negotiation</a></toc>
        <toc class="abstract">The Web assumes an underlying network infrastructure providing a reliable, connection-oriented, flow-controlled, end-to-end transport service. Based on such a network service (today provided by the Internet), the Web's transport protocol moves representations of resources identified by a <em>Uniform Resource Identifier (URI)</em> between Web servers and clients. The most important protocols for data transfer on the Web is the <em>Hypertext Transfer Protocol (HTTP)</em>.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<slide>
			<title>Web Server Service</title>
			<ul>
				<li>Web servers do more than just <q>deliver files</q></li>
				<li>They receive a request for acting on a resource</li>
				<ul>
					<li>this may be a simple file retrieval</li>
					<li>additional information is available from the request's <link href="http-headers">header fields</link></li>
					<li>the request URI may contain additional <link href="uri-query">query information</link></li>
					<li>the request may <link href="http-post">transmit complex data</link></li>
				</ul>
				<li>Processing can mean anything, it is transparent for the client</li>
				<ul>
					<li>the result of processing yields a <em>resource representation</em></li>
				</ul>
			</ul>
		</slide>
		<part id="uri">
			<title short="URI">Uniform Resource Identifier (URI)</title>
			<slide>
				<title>Resource Identification</title>
				<ul>
					<li>The Web is centered around resources</li>
					<ul>
						<li>HTTP has been designed to manipulate resources</li>
						<li>HTTP provides methods for getting, putting, updating, and even deleting resources</li>
					</ul>
					<li>Resources are useful abstractions for interfaces</li>
					<ul>
						<li>instead of an API, interaction is built around manipulating resources</li>
						<li>does that sound familiar?</li>
						<li><q><a href="http://www.docengineering.com/">Document exchanges as components of business models</a></q></li>
						<li>APIs change and bind closely, documents can better withstand change and bind loosely</li>
						<li>the whole Web is built around resources, not APIs</li>
						<li><link href="rest"/> is the principle behind this design</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>URI Schemes</title>
				<pre>URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ]</pre>
				<ul>
					<li>URIs in their general case are very simple</li>
					<ul>
						<li>the scheme identifies how resources are identified</li>
						<li>the identification may be hierarchical or non-hierarchical</li>
					</ul>
					<li>Many URI schemes are hierarchical</li>
					<ul>
						<li>it is then possible to use relative URIs such as in <elem>a href="../"</elem></li>
						<li>the slash character is not just a character, in URIs it has semantics</li>
					</ul>
				</ul>
				<blockquote>[…] the URI syntax is a federated and extensible naming system wherein each scheme's specification may further restrict the syntax and semantics of identifiers using that scheme.</blockquote>
				<p class="quotenote"><a href="http://dret.net/rfc-index/reference/RFC3986"><q>Uniform Resource Identifier (URI): Generic Syntax</q>, RFC 3986, January 2005</a></p>
			</slide>
			<slide id="uri-query">
				<title>Query Information</title>
				<ul>
					<li>Query components specify additional information</li>
					<ul>
						<li>it is non-hierarchical information further identifying the resource</li>
						<li>in most cases, it can be regarded as <q>input</q> to the resource</li>
					</ul>
				</ul>
				<blockquote>The query component contains non-hierarchical data that, along with data in the path component […], serves to identify a resource within the scope of the URI's scheme and naming authority […].</blockquote>
				<p class="quotenote"><a href="http://dret.net/rfc-index/reference/RFC3986"><q>Uniform Resource Identifier (URI): Generic Syntax</q>, RFC 3986, January 2005</a></p>
			</slide>
			<slide>
				<title>Processing URIs</title>
				<ul>
					<li>Processing URIs is not as trivial as it may seem</li>
					<ul>
						<li>escaping and normalization rules are non-trivial</li>
						<li>many implementations are broken</li>
						<li>complain about broken implementations</li>
					</ul>
					<li>URIs are not just strings</li>
					<ul>
						<li>URIs are strings with a considerable set of rules attached to them</li>
						<li>implementing all these rules is non-trivial</li>
						<li>implementing all these rules is crucial</li>
						<li>application development environments provide functions for URI handling</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Resources vs. Representations</title>
				<ul>
					<li>URIs identify <em>resources</em></li>
					<ul>
						<li>abstractions which may not have physical representation</li>
					</ul>
					<li>Requesting a URI yields a <em>resource representation</em></li>
					<ul>
						<li>should be an appropriate and useful manifestation of the abstraction</li>
					</ul>
					<li>Resources can have <em>different representations</em></li>
					<ul>
						<li>in a well-designed environment, you should get what works best for you</li>
						<li>HTML for big screens vs. HTML for mobile devices</li>
						<li>an event calendar based on my location and preferences</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part id="http">
			<title short="HTTP">Hypertext Transfer Protocol (HTTP)</title>
			<slide>
				<title>The Web's Protocol</title>
				<img style="height : 60% ; margin : 4% ; float : left ; " src="internet-traffic-trends.png"/>
				<p class="quotenote">provided by <a href="http://www.cachelogic.com/">CacheLogic Inc.</a></p>
			</slide>
			<slide>
				<title>DNS &amp; HTTP</title>
				<p>The two basic protocols which every Web browser must implement are DNS access and HTTP. However, most operating systems provide an API for DNS access, so the browser can use this service locally and only has to implement HTTP. TCP (which is required as the foundation for HTTP) is usually provided by the operating system.</p>
				<img style="width : 90% ; margin : 2% ; " src="browser-dns-http.png"/>
			</slide>
			<part>
				<title>HTTP Basics</title>
				<slide>
					<title>HTTP Messages</title>
					<ul>
						<li>HTTP needs a reliable connection</li>
						<ul>
							<li>the foundation for HTTP is the <link href="tcp"/></li>
							<li>DNS resolution yields an IP address</li>
							<li>open TCP connection to port 80 or port specified in URI (<code>http://rosetta.sims.berkeley.edu:8085/</code>)</li>
						</ul>
						<li>HTTP is a text-based protocol</li>
						<ul>
							<li>the connection is used to transmit text messages</li>
							<li>all HTTP messages are human-readable (not all <em>entities</em>, though)</li>
							<li>basic HTTP operations can be carried out by hand</li>
						</ul>
					</ul>
<pre>start-line
message-header *

message-body ?</pre>
				</slide>
				<slide id="http-headers">
					<title>HTTP Header Fields</title>
					<ul>
						<li>Header fields contain information about the message</li>
						<ul>
							<li><em>general header:</em> <code>Date</code> as the message origination date</li>
							<li><em>request header:</em> <code>Accept-Language</code> indicated language preferences</li>
							<li><em>response header:</em> <code>Server</code> contains system information</li>
							<li><em>entity header:</em> <code>Content-Type</code> specifies the media type of the entity</li>
						</ul>
						<li>HTTP defines <a href="http://www.cs.tut.fi/~jkorpela/http.html">a number of header fields</a></li>
						<ul>
							<li>unknown fields must be ignored (extensibility)</li>
							<li>unstandardized fields should use a <q><code>X-</code></q> prefix</li>
						</ul>
						<li>HTTP is about acting on these fields</li>
						<ul>
							<li>HTTP defines what HTTP implementations must or should do</li>
						</ul>
					</ul>
				</slide>
				<slide id="http-request">
					<title>HTTP Requests</title>
					<ul>
						<li>After opening a connection, the client sends a request</li>
						<ul>
							<li>the method indicates the action to be performed on the resource</li>
							<li>HTTP's most interesting methods are: <code>GET</code>, <code>HEAD</code>, <code>POST</code></li>
							<li>other interesting methods are: <code>PUT</code>, <code>DELETE</code></li>
						</ul>
						<li>The URI identifies the resource to which the request should be applied</li>
						<ul>
							<li>absolute URIs are required when contacting <link href="proxies"/></li>
							<li>absolute paths are required when contacting a server directly</li>
							<li>the URI may contain <link href="uri-query"/></li>
							<li>fragment identifiers are not sent (they are interpreted on the client side)</li>
						</ul>
						<li>The <code>Host</code> header field must be included in every request</li>
					</ul>
<pre>Method Request-URI HTTP/Major.Minor
[Header]*

[Entity]?</pre>
				</slide>
				<slide id="http-get">
					<title>HTTP GET</title>
					<ul>
						<li>Retrieval action based on the URI</li>
						<ul>
							<li>maybe implemented by reading a file</li>
							<li>maybe implemented by processing a file (PHP)</li>
							<li>maybe implemented by invoking a process</li>
						</ul>
						<li>Semantics may change based on header fields</li>
						<ul>
							<li><code>If-*:</code> only reply with the entity if necessary</li>
							<li><code>Range:</code> only reply with the requested part of the entity</li>
						</ul>
						<li>Cacheability depends on header fields of the response</li>
					</ul>
<pre>GET / HTTP/1.1
Host: ischool.berkeley.edu</pre>
				</slide>
				<slide id="http-response">
					<title>HTTP Responses</title>
					<ul>
						<li>The server's response to interpreting a request</li>
						<ul>
							<li>the status code is given numerically and as text</li>
							<li><code>2**</code> for variations of <q>ok</q></li>
							<li><code>3**</code> for redirections</li>
							<li><code>4**</code> are different client side problems (<code>404</code>: not found)</li>
							<li><code>5**</code> are different server side problems</li>
						</ul>
						<li>Header fields specify additional information</li>
						<ul>
							<li>information about the server</li>
							<li>information about the entity (media type, encoding, language)</li>
						</ul>
					</ul>
<pre>HTTP/Major.Minor Status-Code Text
[Header]*

[Entity]?</pre>
				</slide>
				<slide id="http-performance">
					<title>HTTP Performance</title>
					<ul>
						<li>HTTP/1.0 allowed one transaction per connection</li>
						<ul>
							<li>TCP connection setup and teardown are expensive</li>
							<li>TCP's <em>slow start</em> slows down the initial phase of data transfer</li>
							<li>typical Web pages use between 10-20 resources (HTML + images)</li>
							<li>typically, these resources are stored on the same server</li>
						</ul>
						<li>HTTP/1.1 introduces <em>persistent connections</em></li>
						<ul>
							<li>the TCP connection stays open for some time (10 sec is a popular choice)</li>
							<li>additional requests to the same server use the same TCP connection</li>
						</ul>
						<li>HTTP/1.1 introduces <em>pipelined connections</em></li>
						<ul>
							<li>instead of waiting for a response, requests can be queued</li>
							<li>the server responds as fast as possible</li>
							<li>the order may not be changed (there is no sequence number)</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>HTTP Connection Handling</title>
					<img style="width : 90% ; margin : 2% ; " src="http-phttp-pipelining.png"/>
				</slide>
			</part>
			<part id="http-content-negotiation">
				<title>Content Negotiation</title>
				<slide>
					<title>What is Content Negotiation?</title>
					<ul>
						<li>Negotiation between two HTTP peers</li>
						<ul>
							<li>resources may be available in different representations</li>
							<li>possible dimensions are language, graphics format, character encoding, …</li>
							<li>using <u>one</u> URI, it should be possible to get the <q>best</q> resource</li>
						</ul>
						<li>Negotiation requires knowledge about the resource user</li>
						<ul>
							<li>languages depend on humans reading pages</li>
							<li>graphics formats depend on the browser's functionality</li>
						</ul>
						<li>Content negotiation is a form of a Web-based service</li>
						<ul>
							<li>client request a URI and have some constraints</li>
							<li>using these constraints, the best representation should be served</li>
							<li>ideally, content negotiation should not be too expensive</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Three Different Variants</title>
					<ul>
						<li>Server Side Content Negotiation</li>
						<ul>
							<li>the server has a set of representations and information from the request</li>
							<li>the server returns the <q>best</q> representation based on the request</li>
						</ul>
						<li>Client Side Content Negotiation</li>
						<ul>
							<li>the server responds with a list of different representations</li>
							<li>the client (browser or user) makes a choice and sends a second request</li>
						</ul>
						<li>Transparent Content Negotiation</li>
						<ul>
							<li>Caches act as in client side negotiation and thus know the available representations</li>
							<li>Clients contacting the cache can be served by the cache as in server side negotiation</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Server Side Content Negotiation</title>
					<ul>
						<li>Clients usually tell something about themselves</li>
						<ul>
							<li><code>Accept</code>, <code>Accept-Charset</code>, <code>Accept-Encoding</code>, <code>Accept-Language</code></li>
							<li>the server also knows their IP address</li>
							<li>the server may also use additional information (<link href="cookie"/>s)</li>
						</ul>
						<li>The server needs to find the <q>best representation</q></li>
						<ul>
							<li>most easily by matching the request with available representations</li>
							<li>could also be implemented more dynamically by generating new representations</li>
						</ul>
					</ul>
				</slide>
			</part>
		</part>
		<part id="proxies">
			<title>Proxies</title>
			<slide>
				<title>Proxies</title>
				<ul>
					<li>HTTP often is end-to-end</li>
					<ul>
						<li>there is a direct connection between my browser and the server</li>
						<li>HTTP allows using proxies, which are HTTP intermediaries</li>
					</ul>
					<li>Proxies are used for security reasons</li>
					<ul>
						<li>a proxy is an important part of a firewall</li>
						<li>it hides the user's identity by acting on behalf of the user</li>
						<li>proxies are ideally suited for logging and filtering</li>
					</ul>
					<li>Proxies are used for performance reasons</li>
					<ul>
						<li>requests and responses can be cached, speeding up responses significantly</li>
						<li>caching depends on the ability to know when the cache is outdated</li>
						<li>HTTP enables proxies to validate their cached copies</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Browsers &amp; Proxies</title>
				<p>A <em>proxy</em> is configured in the browser (manually or automatically), so that the browser sends all requests to the proxy instead of the target Web server. The proxy then forwards the request. Proxies can be chained, so that the requests and responses travel through a number of HTTP systems.</p>
				<img style="width : 90% ; margin : 2% ; " src="proxy.png"/>
			</slide>
			<slide id="firewalls">
				<title>Firewalls</title>
				<ul>
					<li>Firewalls are used to protect computers</li>
					<ul>
						<li>protecting users from worms and viruses</li>
						<li>protecting servers from intrusion attacks</li>
						<li>firewalls analyze and block traffic based on complex rules</li>
					</ul>
					<li>A <em>reverse proxy</em> can be part of a firewall concept</li>
					<ul>
						<li>it is configured and maintained by the service provider</li>
						<li>it is a single access point through which HTTP traffic goes</li>
						<li>it is good because it bundles access control to servers behind it</li>
						<li>it is bad because it is a <em>single point of failure</em></li>
					</ul>
				</ul>
			</slide>
		</part>
		<part>
			<title>Conclusions</title>
			<slide>
				<title>Web Server Service</title>
				<ul>
					<li>HTTP is much more than file transfer</li>
					<ul>
						<li>it is a protocol for the concept of <em>resource manipulation</em></li>
						<li>it is a distinct step away from the <em>API approach</em> to building distributed systems</li>
					</ul>
					<li>HTTP servers can be configured to deliver good or bad service</li>
					<ul>
						<li>this is a question of how well they are configured on the HTTP level</li>
						<li>it is also a question of how good the Web design is</li>
						<li>both issues together are required to set up a good Web server</li>
					</ul>
				</ul>
			</slide>
		</part>
    </presentation>
    <presentation id="security">
        <title short="Security">Security Issues</title>
        <date>2007-09-11</date>
        <toc class="resources"><a href="http://dret.net/rfc-index/reference/RFC4346" title="TLS RFC">TLS</a>&#160;· <a href="http://www.simonsingh.net/The_Code_Book.html">Code Book</a></toc>
        <toc class="abstract">TCP and thus HTTP are clear-text protocols, which make no attempt to hide the data being transmitted. For secure data transfers, it thus is necessary to use additional technologies for providing secure data transfers. This lecture looks briefly into the foundations of <em>cryptographic primitives</em> (such as one-way functions and encryption) and <em>cryptographic protocols</em>. For the Web, the most interesting security feature are secure HTTP interactions, which are provided by <em>HTTP over SSL (HTTPS)</em>, a protocol that layers an encryption layer (<em>SSL</em> or <em>TLS</em>) between TCP and HTTP.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<part id="security-101">
			<title>Security 101</title>
			<slide>
				<title>Cryptography</title>
				<ul>
					<li>Cryptography is structured into different layers</li>
					<ul>
						<li>layering is a well-established principle for <em>separation of concerns</em></li>
					</ul>
					<li><em>Cryptographic primitives</em> implement very basic functionality</li>
					<ul>
						<li>changes and advancements in this area are limited to very specialized researchers</li>
						<li>it is easy to make fatal mistakes which then challenge everything built on top if it</li>
					</ul>
					<li><em>Cryptographic protocols</em> assemble primitives into application-level solutions</li>
					<ul>
						<li>primitives solve very basic security problems (fingerprints, encryption, …)</li>
						<li>protocols combine these into applications (digital signatures, secure communications, …)</li>
					</ul>
				</ul>
			</slide>
			<part id="one-way-function">
				<title>One-Way Function</title>
				<slide>
					<title>Essence of Data</title>
					<ul>
						<li>Hashes (or <em>message digests</em>) are a well-known principle in computer science</li>
						<ul>
							<li>fast to compute (the goal is to make data handling more efficient)</li>
							<li>few collisions (there are always collisions because of the smaller size)</li>
							<li><em>checksums</em> and <em>Cyclic Redundancy Check (CRC)</em> are popular hashes</li>
						</ul>
						<li>One-way functions are cryptographically safe hashes</li>
						<ul>
							<li>not just for detecting errors, but also for preventing tampering</li>
							<li>often referred to as <em>cryptographic hash</em> or <em>digital fingerprint</em></li>
						</ul>
						<li>One-way functions must satisfy additional criteria</li>
						<ul>
							<li>it must be very hard to find an input producing a given output</li>
							<li>it must be very hard to find two inputs producing the same output (<q>collision</q>)</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Reducing Data</title>
					<img style="width : 90% ; margin : 2% ; " src="hash.gif" title="Hash" href="http://www.int.gu.edu.au/courses/2010int/crypto.html"/>
				</slide>
			</part>
			<part>
				<title>Secret-Key Cryptography</title>
				<slide>
					<title>Plausible Encryption</title>
					<ul>
						<li>Secret-Key is was most people think of when thing of encryption</li>
						<ul>
							<li><em>Symmetric cryptography</em> is another popular term</li>
						</ul>
						<li>One key for encryption and decryption</li>
						<li>Losing the key makes encrypted data openly readable</li>
						<ul>
							<li>there must be a secure channel to transport keys</li>
						</ul>
						<li>Good for long-term relationships with few partners</li>
						<ul>
							<li>exchange secret keys as part of the initial setup of a relationships</li>
							<li>adding partners requires a <em>secure channel</em> for key exchange</li>
							<li>changing keys requires a <em>secure channel</em> for key exchange</li>
						</ul>
						<li>Almost impractical in an environment with many ad-hoc partners</li>
					</ul>
				</slide>
				<slide>
					<title>Notice the Arrow</title>
					<img style="width : 90% ; margin : 2% ; " src="secret-key.gif" title="Secret-Key Cryptography" href="http://www.int.gu.edu.au/courses/2010int/crypto.html"/>
				</slide>
			</part>
			<part>
				<title>Public-Key Cryptography</title>
				<slide>
					<title>Implausible Encryption</title>
					<ul>
						<li>Public-Key intuitively is hard to accept as a concept</li>
						<ul>
							<li><em>Asymmetric cryptography</em> is another popular term</li>
						</ul>
						<li>Key pairs of one public and one secret key</li>
						<ul>
							<li><em>key generation</em> is the process of generating these key pairs</li>
						</ul>
						<li>The public key can be made available to the public</li>
						<ul>
							<li>only the secret key can do the inverse operation of the public key</li>
						</ul>
						<li>Good for short-term relationships with many partners</li>
						<ul>
							<li>publish your public key so that it can be used worldwide</li>
							<li>everybody can encrypt data using the public key</li>
							<li>only the owner of the secret can can decrypt the message and read it</li>
						</ul>
						<li>Computationally expensive and not good for a large amounts of data</li>
					</ul>
				</slide>
				<slide>
					<title>No Arrow Here …</title>
					<img style="width : 90% ; margin : 2% ; " src="public-key-public-encrypt.gif" title="Public-Key Cryptography (Encrypting with Public Key)" href="http://www.int.gu.edu.au/courses/2010int/crypto.html"/>
				</slide>
				<slide>
					<title>And No Arrow Here …</title>
					<img style="width : 90% ; margin : 2% ; " src="public-key-secret-encrypt.gif" title="Public-Key Cryptography (Encrypting with Secret Key)" href="http://www.int.gu.edu.au/courses/2010int/crypto.html"/>
				</slide>
			</part>
		</part>
		<part>
			<title>Cryptographic Protocols</title>
			<slide>
				<title>Building Secure Applications</title>
				<ul>
					<li><em>Cryptographic primitives</em> in most cases are not sufficient</li>
					<ul>
						<li>they provide basic functionality for fundamental tasks</li>
						<li>they must by combined to provide solutions for real-world problems</li>
					</ul>
					<li>Typical problem: How to ensure key authenticity</li>
					<ul>
						<li>with insecure keys, the majority of cryptographic methods is worthless</li>
					</ul>
					<li>Typical problem: How to communicate securely without shared keys</li>
					<ul>
						<li>secret-key does not work, public-key needs to verify the peer</li>
					</ul>
					<li>Typical problem: How to check authenticity and integrity of data</li>
					<ul>
						<li>integrity can be done with checksums, but these could be forged</li>
						<li>authenticity needs a cryptographically secure way of combining identity and data</li>
					</ul>
				</ul>
			</slide>
			<part id="digital-signature">
				<title>Digital Signature</title>
				<slide>
					<title>Encrypted Fingerprints</title>
					<ul>
						<li>Hashes are used to check data integrity</li>
						<li><link href="one-way-function"/>s are used to check data integrity securely</li>
						<ul>
							<li>it is not possible to reverse engineer data for a given hash</li>
						</ul>
						<li>Signed hashes can be used to ensure data authenticity</li>
						<ul>
							<li>if the hash sum is signed, it cannot be changed</li>
							<li>if the data is changed, its hash will not match the signed hash</li>
						</ul>
						<li>Digital signatures work as long as the hash can be securely signed</li>
						<ul>
							<li>there must be a trusted public key for checking the hash signature</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Creating a Digital Signature</title>
					<img style="height : 70% ; margin : 2% ; " src="signature-sign.jpg" href="http://en.wikipedia.org/wiki/Digital_signature"/>
				</slide>
				<slide>
					<title>Verifying a Digital Signature</title>
					<img style="height : 70% ; margin : 2% ; " src="signature-verify.jpg" href="http://en.wikipedia.org/wiki/Digital_signature"/>
				</slide>
				<slide id="certificate">
					<title>Certificate</title>
					<ul>
						<li>Certificates are digital signatures issued by a trusted party</li>
						<ul>
							<li>most digital signatures are created with certified public keys</li>
							<li>this means the digital signature is created based on a digitally signed key</li>
						</ul>
						<li>Who can you trust on the Web?</li>
						<ul>
							<li>trust can only start to grow from some initial trust</li>
							<li>many systems come with pre-installed trust (<em>root certificates</em>)</li>
							<li>certificates from other issuers will cause <a href="https://katapultmedia.com/">browsers to complain</a></li>
						</ul>
						<li>Certificates (like domain names) are a very easy way to make money</li>
						<ul>
							<li>in theory there are different levels of certificates with different levels of identity checking</li>
							<li>in practice most sites choose the cheapest one that does not give an error message</li>
						</ul>
					</ul>
				</slide>
			</part>
			<part>
				<title>Secure Communications</title>
				<slide>
					<title>Encrypted Keys</title>
					<ul>
						<li>Public-Key cryptography is computationally expensive</li>
						<ul>
							<li>it is possible to encrypt all traffic using asymmetric key pairs</li>
							<li>this generates considerably more load on the server side</li>
						</ul>
						<li>Combining public- and secret-key cryptography</li>
						<ol>
							<li>check the public key for authenticity (using a <link href="certificate"/>)</li>
							<li>generate a key for a secret-key encryption scheme</li>
							<li>use the public key to transmit the secret key</li>
							<li>use the secret key for securely transmitting the payload</li>
						</ol>
						<li>Combines the advantages of both primitives</li>
						<ul>
							<li>the better efficiency of secret-key algorithms</li>
							<li>the ability of secret-key algorithms to work without a secure channel</li>
						</ul>
					</ul>
				</slide>
			</part>
		</part>
		<part id="https">
			<title short="HTTPS">HTTP over SSL (HTTPS)</title>
			<slide>
				<title>HTTP and Security</title>
				<ul>
					<li>HTTP sends clear-text messages</li>
					<ul>
						<li>listening to HTTP traffic is trivial</li>
						<li>information transferred via simple HTTP is public</li>
						<li>many Web data transfers (in most cases form data) should be secure</li>
					</ul>
					<li>Making HTTP secure requires additional mechanisms</li>
					<ul>
						<li><em>S-HTTP</em> was an attempt to define a secure version of HTTP</li>
						<li><em>HTTPS</em> uses a secure communication layer underneath HTTP</li>
					</ul>
					<li>Encryption is done by a layer on top of TCP</li>
					<ul>
						<li><em>Secure Sockets Layer (SSL)</em> is the protocol layer invented by Netscape</li>
						<li><link href="tls"/> is the standardized Internet version</li>
					</ul>
				</ul>
			</slide>
			<slide id="s-http">
				<title>HTTPS vs. S-HTTP</title>
				<ul>
					<li>Securing HTTP can be done in two ways</li>
					<ol>
						<li>using a secure communications infrastructure</li>
						<li>making the protocol itself secure (adding cryptographic features)</li>
					</ol>
					<li>Secure infrastructures are better in terms of layering</li>
					<ul>
						<li>they can be reused for other applications (email, file transfer, …)</li>
						<li>they can be evolved independently from the application layer</li>
					</ul>
					<li>Secure protocols can provide better integration of security features</li>
					<ul>
						<li>signed interactions which can be archived for later retrieval</li>
					</ul>
					<li>Layering is more important than tightly integrated security</li>
				</ul>
			</slide>
			<slide>
				<title>HTTP and SSL</title>
				<img style="width : 80% ; margin : 2% ; " src="https.gif" title="HTTP and SSL"/>
			</slide>
			<slide id="tls">
				<title short="TLS">Transport Layer Security (TLS)</title>
				<ul>
					<li>SSL is the name of the old Netscape standard</li>
					<li>TLS is the name of the newer IETF standard</li>
					<li>TLS adds more encryption schemes and more flexibility</li>
				</ul>
			</slide>
			<slide>
				<title>TLS vs. IPsec</title>
				<img style="width : 90% ; margin : 2% ; " src="tls-vs-ipsec.png" title="TLS vs. IPsec"/>
			</slide>
		</part>
		<part>
			<title>Conclusions</title>
			<slide>
				<title>Internet Security</title>
				<ul>
					<li>Certificates are used to guarantee a party's authenticity</li>
					<li>Certificates are digital signatures issued by trusted parties</li>
					<li>One authenticated, public keys can be used to securely communicate</li>
					<li>For efficiency reasons, payload encryption uses secret-key cryptography</li>
					<li>Encryption on the Web is based on HTTPS</li>
					<li>VPN-based encryption can be used to secure all traffic</li>
				</ul>
			</slide>
		</part>
    </presentation>
    <presentation id="authentication">
        <title short="Authentication">Identity and Authentication</title>
        <date>2007-09-13</date>
        <toc class="resources"><a href="http://dret.net/rfc-index/reference/RFC2617" title="HTTP Authentication RFC">HTTP Authentication Spec</a></toc>
        <toc class="abstract">For any task involving personalization and/or trust, it is not only necessary to have a concept for providing privacy, but also to have concepts for <em>identity</em> and how to prove identity, which needs <em>authentication</em>. HTTP has built-in mechanisms for authentication, and the standard <em>HTTP Authentication</em> mechanisms are <em>Basic Authentication</em> and <em>Digest Access Authentication</em>. Instead of these mechanisms, many applications implement their own ways of authentication, which often are based around authentication using <em>HTML Forms</em>.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<part>
			<title>Anonymous Authenticity</title>
			<slide>
				<title>Certificates and Identity</title>
				<ul>
					<li>What can you be certain of when using <link href="https">HTTPS</link>?</li>
					<ul>
						<li>in most cases there only is a server side <link href="certificate"/></li>
						<li>if attackers can manipulate your DNS they can attack HTTPS</li>
					</ul>
					<li>Many scenarios require reliable identification of the client</li>
					<ul>
						<li>HTTPS supports client side certificates for identifying clients</li>
						<li>rarely used outside of closed user groups</li>
					</ul>
					<li>Traditional user identification against a trusted server</li>
					<ul>
						<li>trusted servers can be used for securely transmitting authentication credentials</li>
						<li>identity and authentication methods are handled on a per-server basis</li>
						<li>when using many services, users end up with many identities</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Usernames and Password</title>
				<ul>
					<li>Usernames represent identities</li>
					<ul>
						<li>whoever uses the name is <em>identical with the user</em></li>
						<li>giving away the username means giving away the identity</li>
					</ul>
					<li>Passwords are used to authenticate a user</li>
					<ul>
						<li>identities are secured and checked by using password</li>
						<li>giving away the password means giving away the authenticity</li>
					</ul>
					<li>Usernames and passwords must be handled securely</li>
					<ul>
						<li>transmitting them in clear text (such as <link href="http">HTTP</link>) is a very bad idea</li>
						<li>reusing username/password pairs is a risky practice</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part id="http-authentication">
			<title>HTTP Authentication</title>
			<slide>
				<title>HTTP Access Control</title>
				<ul>
					<li>HTTP servers can <a href="http://en.wikipedia.org/wiki/List_of_HTTP_status_codes#4xx_Client_Error">deny access</a> because of access control</li>
					<ul>
						<li><code>401 Unauthorized</code> means the resource is access controlled</li>
						<li><code>403 Forbidden</code> means the resource is inaccessible</li>
						<li><code>405 Method Not Allowed</code> signals a request using the wrong <link href="http-request">request method</link></li>
					</ul>
					<li>Two different approaches to unauthorized access are possible</li>
					<ul>
						<li>repeat the HTTP request with the proper authentication credentials</li>
						<li>redirect to a <link href="login-page"/> and establish an authenticated <link href="session"/></li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>HTTP Authentication</title>
				<img style="width : 90% ; margin : 2% ; " src="authentication-http.gif" title="HTTP Authentication" href="http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Security5.html"/>
			</slide>
			<part id="basic-authentication">
				<title>Basic Authentication</title>
				<slide id="realm">
					<title>Authentication Information</title>
					<ul>
						<li>Authentication is based on <em>authentication realms</em></li>
						<ul>
							<li>a set of resources for which the authentication is required</li>
							<li>an opaque name which is used to signal which login is required</li>
							<li>username/password probably is specific for a given realm</li>
						</ul>
						<li>Users supply username and password through the client</li>
						<ul>
							<li>sent as <a href="http://en.wikipedia.org/wiki/Base64">Base64</a> encoded <code>username:password</code> string</li>
							<li>username and password are <a href="http://www.google.com/search?hl=en&amp;q=base64+decoder"><em>not</em> transmitted securely</a></li>
							<li>basic authentication should <em>always</em> use <link href="https">HTTPS</link></li>
						</ul>
						<li>Authorization is handled on the server side</li>
					</ul>
					<pre href="http://en.wikipedia.org/wiki/Basic_access_authentication">HTTP/1.0 401 Unauthorized
WWW-Authenticate: Basic realm="SokEvo"</pre>
					<pre href="http://en.wikipedia.org/wiki/Basic_access_authentication">GET /private/index.html HTTP/1.0
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==</pre>
				</slide>
				<slide>
					<title>Repeated Access</title>
					<ul>
						<li>Clients typically access more than one protected resource</li>
						<ul>
							<li>a perfectly stateless client would always request authentication from the user</li>
							<li>using the <link href="realm"/> clients can identify repeated accesses</li>
						</ul>
						<li>Clients remember the authentication and replay it automatically</li>
						<ul>
							<li>browsers provide little control over this feature</li>
							<li><q>logging out</q> of HTTP authenticated sessions is hard</li>
						</ul>
					</ul>
				</slide>
			</part>
			<part id="digest-authentication">
				<title>Digest Access Authentication</title>
				<slide>
					<title>Better HTTP Authentication</title>
					<ul>
						<li><link href="basic-authentication"/> is a serious security problem</li>
						<ul>
							<li>username and password are transmitted unencrypted</li>
						</ul>
						<li><em>Digest Access Authentication</em> does not require transmission of the password</li>
						<ul>
							<li>only information computed using a <link href="one-way-function"/> is transmitted via HTTP</li>
							<li>server-side needs clear-text password to compute HTTP header values</li>
						</ul>
						<li>Three-step one-way function calculation of <http>response</http> value</li>
						<ol>
							<li>HA1 = MD5(username, realm, password)</li>
							<li>HA2 = MD5(HTTP method, request URI)</li>
							<li>Response = MD5(HA1, nonce, nc, cnonce, qop, HA2)</li>
						</ol>
						<li>Server responses may include <http>AuthenticationInfo</http></li>
						<ul>
							<li>information for the next authenticated request</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Example Headers</title>
					<pre href="http://en.wikipedia.org/wiki/Digest_access_authentication">HTTP/1.0 401 Unauthorized
WWW-Authenticate: Digest realm="testrealm@host.com",
	qop="auth,auth-int",
	nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
	opaque="5ccc069c403ebaf9f0171e9517f40e41"</pre>
					<pre href="http://en.wikipedia.org/wiki/Digest_access_authentication">GET /dir/index.html HTTP/1.0
Authorization: Digest username="Mufasa",
	realm="testrealm@host.com",
	nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
	uri="/dir/index.html",
	qop=auth,
	nc=00000001,
	cnonce="0a4f113b",
	response="6629fae49393a05397450978507c4ef1",
	opaque="5ccc069c403ebaf9f0171e9517f40e41"</pre>
				</slide>
			</part>
		</part>
		<part id="app-authentication">
			<title>Application Authentication</title>
			<slide id="login-page">
				<title>Login Page</title>
				<ul>
					<li><link href="http-authentication"/> works with browser controls (including window)</li>
					<ul>
						<li>no possibility to <q>log out</q> without using browser-specific controls</li>
						<li>client side security depends on browser security measures</li>
					</ul>
					<li>Using <link href="forms"/> gives more freedom in session management</li>
					<ul>
						<li>authentication and authorization are completely application-based</li>
						<li>if there were <q>secure personal browsers</q> this would not work very well</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>HTTP and Form-Based Login</title>
				<ul>
					<li>HTTP is used inconsistently with form-based login</li>
					<ul>
						<li>some frameworks use redirections to login pages and then to resources</li>
						<li>some frameworks use login pages as front ends to protected resources</li>
					</ul>
					<li>HTTP messages never indicate any kind of authentication problem</li>
					<ul>
						<li><http>302 Found</http> is being sent for unauthenticated access (<http>Location</http> login page)</li>
						<li>successful login redirects to the original resource</li>
						<li><http>401 Unauthorized</http> signals missing authorization (no <http>WWW-Authenticate</http>)</li>
					</ul>
					<li>Use HTTP to display login pages</li>
					<ul>
						<li><http>403 Forbidden</http> when requesting a protected page without credentials</li>
						<li>send the login page as the HTML in the response</li>
						<li>after authentication and authorization serve the same page as <http>200 OK</http></li>
					</ul>
					<li>The <q>login representation</q> is the preferred method</li>
				</ul>
			</slide>
			<slide>
				<title>Form-Based Authentication</title>
				<img style="width : 90% ; margin : 2% ; " src="authentication-form.gif" title="Form-Based Authentication" href="http://java.sun.com/j2ee/1.4/docs/tutorial/doc/Security5.html"/>
			</slide>
			<slide>
				<title>HTML Session Management</title>
				<listing src="html-form-state.xml"/>
			</slide>
		</part>
		<part>
			<title>Conclusions</title>
			<slide>
				<title>Web or Application Architecture</title>
				<ul>
					<li><link href="http-authentication"/> uses standards and standard mechanisms</li>
					<ul>
						<li><link href="basic-authentication"/> <em>should always use</em> <link href="https">HTTPS</link></li>
						<li><link href="digest-authentication"/> can be safely used over unencrypted connections</li>
					</ul>
					<li><link href="app-authentication"/> uses fewer Web methods</li>
					<ul>
						<li>some frameworks use <q>login representations</q> for protected resources</li>
						<li>some frameworks use redirects to channel requests through a login page</li>
					</ul>
				</ul>
			</slide>
		</part>
	</presentation>
    <presentation id="state">
        <title short="State">State Management</title>
        <date>2007-09-18</date>
        <toc class="reading"><a href="http://en.wikipedia.org/wiki/HTTP_cookie" title="Wikipedia about HTTP Cookies">Wikipedia</a></toc>
        <toc class="resources"><a href="http://www.w3.org/2001/tag/doc/state.html" title="State in Web Application Design">State</a>&#160;· <a href="http://dret.net/rfc-index/reference/RFC2965" title="Cookies RFC">Cookies Spec</a></toc>
        <toc class="abstract">HTTP is a stateless protocol, where each request/response interaction is a separate interaction and there is no protocol support for longer sessions (such as a user logging in and working on a Web site as an identified user). <em>State management</em> refers to mechanisms which provide support for this kind of scenario, the most popular choice for state management are <em>cookies</em>. Another possibility is URI-based state management. This lecture is a first glimpse into the world of <em>Representational State Transfer (REST)</em>, the Web's fundamental model of handling interaction with resources.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<part id="session">
			<title>Session</title>
			<slide>
				<title>HTTP and Sessions</title>
				<ul>
					<li>HTTP has no session concept</li>
					<ul>
						<li>interactions are HTTP request/response pairs and not site visits</li>
						<li><link href="http-performance">HTTP/1.1</link> does not change this, it is only a performance optimization</li>
						<li>servers can not reliably identify users interacting with a Web site</li>
					</ul>
					<li>Sessions should not be used to track resource state</li>
					<ul>
						<li>the semantics of resource interactions should not depend on client state</li>
						<li>application behavior can depend on client state</li>
					</ul>
					<li>HTTP's concept of <em>stateless interaction</em> is important</li>
					<ul>
						<li>the Web's idea is to use <em>loose coupling</em> between clients and servers/resources</li>
						<li>retrofitting the Web with <em>tight coupling</em> through server state is bad design</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Client-Side State</title>
				<ul>
					<li>Sessions should be maintained on the client</li>
					<ul>
						<li>the client has all relevant information about a session</li>
						<li>when the server restarts, no information will be lost</li>
						<li>if something has to be persistent, it should be a resource</li>
					</ul>
					<li>Small and short-term solutions may work well with server state</li>
					<ul>
						<li><em>scaling</em> these solutions typically introduces many problems</li>
						<li><em>debugging</em> can be hard because the state is transient</li>
						<li><em>integration</em> with other clients can become a difficult problem</li>
					</ul>
					<li>Three ways of client-side state are possible</li>
					<ol>
						<li>sending back and forth state as part of the interaction</li>
						<li>store state in the server and refer to it from the client (not recommended)</li>
						<li>store state at a URI and use the URI to refer to that state</li>
					</ol>
				</ul>
			</slide>
			<slide>
				<title>State in HTML or HTTP</title>
				<img style="width : 90% ; margin : 2% ; " src="web-app-client-state.png" title="State in HTML or HTTP"/>
			</slide>
			<slide>
				<title>State in the Server Application</title>
				<img style="width : 90% ; margin : 2% ; " src="web-app-server-state.png" title="State in the Server Application"/>
			</slide>
			<slide>
				<title>State as a Resource</title>
				<img style="width : 90% ; margin : 2% ; " src="web-app-resource-state.png" title="State as a Resource"/>
			</slide>
			<slide>
				<title>Stateless Shopping</title>
				<ul>
					<li>Typical <q>session scenarios</q> can be <a href="http://www.peej.co.uk/articles/no-sessions.html">mapped to resources</a></li>
					<ul>
						<li>Client: Show me your products</li>
						<li>Server: Here's a list of all the products</li>
						<li>Client: I'd like to buy 1 of http://ex.org/product/X, I am "John"/"Password"</li>
						<li>Server: I've added 1 of http://ex.org/product/X to http://ex.org/users/john/basket</li>
						<li>Client: I'd like to buy 1 of http://ex.org/product/Y, I am "John"/"Password"</li>
						<li>Server: I've added 1 of http://ex.org/product/Y to http://ex.org/users/john/basket</li>
						<li>Client: I don't want http://ex.org/product/X, remove it, I am "John"/"Password"</li>
						<li>Server: I've removed http://ex.org/product/X to http://ex.org/users/john/basket</li>
						<li>Client: Okay I'm done, username/password is "John"/"Password"</li>
						<li>Server: Here is the total cost of the items in http://ex.org/users/john/basket</li>
					</ul>
					<li>This is more than just renaming <q>session</q> to <q>resource</q></li>
					<ul>
						<li>all relevant data is stored persistently on the server</li>
						<li>the shopping cart's URI can be used by other services for working with its contents</li>
						<li>instead of <em>hiding the cart in the session</em>, it is <em>exposed as a resource</em></li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Reusing Resources</title>
				<img style="width : 90% ; margin : 2% ; " src="web-app-reusing-resource.png" title="Reusing Resources"/>
			</slide>
		</part>
		<part id="cookie">
			<title>Cookie</title>
			<slide>
				<title>Tracking Sessions</title>
				<ul>
					<li>Invented as a way to compensate for HTTP's lack of state</li>
					<ul>
						<li>application state is being sent to the client (<http>SetCookie2</http>)</li>
						<li>the client transmits application state in requests (<http>Cookie</http>)</li>
					</ul>
					<li>Cookies do not contain code that is executed</li>
					<ul>
						<li>some data that represents application state (by value or by reference)</li>
						<li>this data is stored by the client and returned to the server</li>
						<li>the client is not supposed to interpret the data in any way</li>
					</ul>
					<li>Cookies can be used in many different ways</li>
					<ul>
						<li>when used for tracking application state they are unproblematic</li>
						<li>when used for tracking resource state they introduce problems</li>
					</ul>
					<li>Cookies tightly bind clients to opaque concepts on the server</li>
				</ul>
			</slide>
			<slide>
				<title>Cookies for State Management</title>
				<img style="width : 90% ; margin : 2% ; " src="web-app-cookie-state.png" title="Cookies for State Management"/>
			</slide>
			<part>
				<title>Third-Party Cookie</title>
				<slide>
					<title>Advertising &amp; Privacy</title>
					<ul>
						<li>Big ad servers are digital hubs in the commercial Web</li>
						<ul>
							<li>consumers switch content providers but get the same ad provider</li>
							<li>tracking consumers <em>across</em> content providers is very valuable</li>
						</ul>
						<li>Cookies set by ad providers are sent very frequently</li>
						<ul>
							<li>each site that uses the ad provider triggers the cookies to be sent</li>
							<li>detailed profiling can be employed for creating consumer profiles</li>
						</ul>
						<li>Content and ad providers can cooperate for better profiling</li>
						<ul>
							<li>consumers log in to content providers are are reliably identified</li>
							<li>their personal profile can be matched with the ad provider's profile</li>
							<li>ad provider consolidation makes this scenario realistic</li>
						</ul>
					</ul>
				</slide>
			<slide>
				<title>Browsers Assemble Web Pages</title>
				<p>Typical Web resources (HTML pages) are assembled from a number of resources retrieved by HTTP. Any resource not originating on the server that is hosting the HTML page is considered a <q>third-party resource</q>. If the HTTP response for such a resource contains a cookie, it is a <q>third-party cookie</q>.</p>
				<img style="width : 90% ; margin : 2% ; " src="third-party-cookie.png" title="Third Party Cookie"/>
			</slide>
			</part>
		</part>
		<part>
			<title>Cookie-Less State Tracking</title>
			<slide>
				<title>Cookie Support</title>
				<ul>
					<li>Authentication can be tracked with <link href="http-authentication"/></li>
					<ul>
						<li>this is possible because authentication is built into HTTP</li>
					</ul>
					<li>Other session concepts are not supported by HTTP</li>
					<ul>
						<li>cookies have become the generic solution for all session tracking</li>
					</ul>
					<li>Cookies are increasingly limited by browsers</li>
					<ul>
						<li>cookies have gained some notoriety as privacy invaders</li>
						<li>browser have more restrictive default settings</li>
						<li>an increasing number of users restricts cookie support</li>
					</ul>
					<li>Session-oriented Web sites often depend on cookies</li>
				</ul>
			</slide>
			<slide id="uri-rewriting">
				<title>URI Rewriting</title>
				<ul>
					<li><link href="cookie"/>s are a piece of information stored on the client</li>
					<ul>
						<li>they are sent by the server as a result of a request</li>
						<li>they are returned by the browser in a response to the same site</li>
					</ul>
					<li>The same information can also be encoded in the URI</li>
					<ul>
						<li>normally a response contains a cookie and an HTML page</li>
						<li>the same effect is achieved when all links include the <q>cookie value</q></li>
						<li>this method often results in very long URIs</li>
					</ul>
					<li>Some Web application frameworks switch automatically</li>
					<ul>
						<li>J2EE checks for cookie support and switches to URI rewriting if required</li>
					</ul>
					<li>Problems with bookmarks and caches</li>
				</ul>
			</slide>
			<slide>
				<title>Hidden Form Fields</title>
				<ul>
					<li><link href="cookie"/>s transmit session information via HTTP</li>
					<li><link href="uri-rewriting"/> encodes session information in URIs</li>
					<li><link href="forms"/> are a way to send data to a server</li>
					<ul>
						<li>in most cases this is data that is entered by the user</li>
					</ul>
					<li>Hidden form fields can be used to send data that is part of the HTML</li>
					<ul>
						<li>hidden form fields are never displayed to the user</li>
						<li>their predefined values are sent as part of the form submission</li>
					</ul>
					<li>Hidden form fields are essentially the same as <link href="uri-rewriting"/></li>
					<ul>
						<li>they can only be used if the interaction is based on forms</li>
						<li>they also require the Web page to be dynamically generated for each request</li>
						<li>the values end up as URI query string or request entity</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part>
			<title>Conclusions</title>
			<slide>
				<title>Session for Application State</title>
				<ul>
					<li>Sessions should only be used for application state</li>
					<li>Cookies are the best way to track sessions</li>
					<ul>
						<li>cookies should be self-contained rather than referential</li>
					</ul>
					<li>Alternative methods are URI rewriting and hidden form fields</li>
					<ul>
						<li>more robust than cookies but unpleasant side-effects</li>
					</ul>
				</ul>
			</slide>
		</part>
    </presentation>
    <presentation id="rest">
        <title short="REST">Representational State Transfer (REST)</title>
        <date>2007-09-20</date>
        <toc class="reading"><a href="http://www.mulberrytech.com/Extreme/Proceedings/html/2002/Prescod01/EML2002Prescod01.html" title='P. Prescod, "Roots of the REST/SOAP Debate", Extreme Markup Languages Conference, August 2002'>REST vs. SOAP</a>&#160;· <a href="http://www.eioba.com/a69755/how_i_explained_rest_to_my_wife">What is REST?</a>&#160;· <a href="http://bitworking.org/news/193/Do-we-need-WADL">REST Interfaces</a></toc>
        <toc class="resources"><a href="http://rest.blueoxen.net/cgi-bin/wiki.pl">RESTwiki</a></toc>
        <toc class="abstract"><em>Representational State Transfer (REST)</em> is an architectural style for building distributed systems. The Web is an example for such a system. REST-style applications can be built using a wide variety of technologies. REST's main principles are those of resource-oriented states and functionalities, the idea of a unique way of identifying resources, and the idea of how operations on these resources are defined in terms of a single protocol for interacting with resources. REST-oriented system design leads to systems which are open, scalable, extensible, and easy to understand.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<slide>
			<title>The Web as a System</title>
			<ul>
				<li>The Web is one distributed hypermedia system</li>
				<ul>
					<li>the main architectural components are URIs, HTTP, and HTML</li>
					<li>all other Web technologies are built on that foundation</li>
					<li>if they are not, they are very likely not well-designed Web technologies</li>
				</ul>
				<li>The Web is amazingly open, scalable, extensible, and easy to understand</li>
				<ul>
					<li><em>openness</em> allows new technologies to be introduced</li>
					<li><em>scalability</em> ensures that the system does not contain bottlenecks</li>
					<li><em>extensibility</em> allows the Web to evolve without any redesign of existing parts</li>
					<li><em>simplicity</em> makes sure that the system survives and evolves</li>
				</ul>
				<li>No other information system gets even close to the Web</li>
				<ul>
					<li>but not all information system designs can accept the Web's limitations</li>
					<li>REST should be seen as a guideline how to build a true Web application</li>
					<li>other applications will continue to be built using other approaches</li>
				</ul>
			</ul>
		</slide>
		<slide>
			<title>Web System Design</title>
			<blockquote>There are two ways of constructing a software design: One way is to make it so simple that there are <em>obviously</em> no deficiencies, and the other way is to make it so complicated that there are no <em>obvious</em> deficiencies. The first method is far more difficult.</blockquote>
			<p class="quotenote"><a href="http://en.wikipedia.org/wiki/Charles_Antony_Richard_Hoare">C. A. R. Hoare</a>, <a href="http://dret.net/biblio/reference/hoa81"><q>The Emperor's Old Clothes</q>, 1980 Turing Award Lecture</a></p>
		</slide>
		<part>
			<title>Technologies and Implementations</title>
			<slide>
				<title>Object-Orientation</title>
				<ul>
					<li>Object-Orientation is a <em>Software Engineering Style</em></li>
					<ul>
						<li>it can be applied to any programming language</li>
						<li>depending on the language, this is more or less easy</li>
						<li>OO languages support or even enforce certain design patterns</li>
						<li><em>spaghetti code</em> can be written in every programming language</li>
					</ul>
					<li>Implementations can always be bad or good</li>
					<ul>
						<li>the quality of the implementation depends on the programmer</li>
						<li>programmers can be better supported and controlled with an OO language</li>
						<li>implementation quality metrics must be based on the product, not the language</li>
					</ul>
					<li>Good programmers always produce good code</li>
					<li>Bad programmers always produce bad code</li>
					<li>Average programmers need good tools to produce good code</li>
				</ul>
			</slide>
			<slide>
				<title>Technologies are Tools</title>
				<ul>
					<li>Technologies help solving problems</li>
					<ul>
						<li>they are built with certain goals in mind</li>
						<li>they specialize in solving a problem <em>in a specific way</em></li>
					</ul>
					<li>Technology choices are very important</li>
					<ul>
						<li>the technology (i.e., the tool) shapes the way how a problem is solved</li>
						<li>working <q>against</q> the tool is possible, but hard and rarely done</li>
					</ul>
					<li>Technologies sometimes cloud the more important issues</li>
					<ol>
						<li>the problem must be well-defined and fully understood</li>
						<li>the general approach to solve a problem must be identified</li>
						<li>finally, a technology supporting this approach must be chosen</li>
					</ol>
				</ul>
			</slide>
			<slide>
				<title>Implementations are Products</title>
				<ul>
					<li>Implementations are built on (and shaped by) technologies</li>
					<li>Implementation = Concepts + Technologies</li>
					<li>Implementation quality depends on both factors</li>
					<ul>
						<li>the right choice of technologies is very important</li>
						<li>the responsible use of that foundation is equally important</li>
					</ul>
					<li>Good REST is as hard to grasp as good OO</li>
					<ul>
						<li>products may claim that they are REST/OO</li>
						<li>they may even use technologies which support REST/OO</li>
						<li>only careful inspection reveals the truth of this claim</li>
						<li>in most cases, this only happens when the product needs to be changed</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part id="rest-principle">
			<title>REST Principles</title>
			<slide>
				<title>Definition</title>
				<ul>
					<li>Resources are defined by URIs</li>
					<li>Resources are manipulated through their representations</li>
					<li>Messages are self-descriptive and stateless</li>
					<li>There can be multiple representations for a resource</li>
					<li>Application state is driven by resource manipulations</li>
				</ul>
			</slide>
			<slide>
				<title>Resources</title>
				<ul>
					<li>Resources are defined by URIs</li>
					<ul>
						<li>resources can never be accessed or manipulated directly</li>
						<li>REST works with resource representations</li>
					</ul>
					<li>Resources are all the things we want to work with</li>
					<ul>
						<li>if you cannot name something, you cannot do anything with it</li>
						<li>a popular resource type on the Web are documents</li>
						<li>documents usually are a structured collection of information</li>
					</ul>
					<li>Documents are abstract concepts of descriptive resources</li>
					<ul>
						<li>they may be used in different contexts (e.g., formats)</li>
						<li>different applications may be interested in different representations</li>
						<li>the underlying resource is always the same</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>State</title>
				<ul>
					<li>State is represented as part of the content being transferred</li>
					<ul>
						<li>server interruptions do not create problems for the client</li>
						<li>it is possible to switch between servers for different interactions</li>
						<li>clients can simply store the representation to save the state</li>
					</ul>
					<li>State transfer makes the system scalable</li>
					<ul>
						<li>data transfer is not state-specific (no stateful connection handling)</li>
						<li>state is transferred between client and server</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Establishing a Common Model</title>
				<ul>
					<li>Distributed systems must be based on a shared model</li>
					<ul>
						<li>traditional systems must agree on a common API</li>
						<li>REST systems structure agreement into three areas</li>
					</ul>
					<li>REST is built around the idea of simplifying agreement</li>
					<ul>
						<li><em>nouns</em> are required to name the resources that can be talked about</li>
						<li><em>verbs</em> are the operations that can be applied to named resources</li>
						<li><em>content types</em> define which information representations are available</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>REST Triangle</title>
				<img style="height : 70% ; margin : 2% ; " src="rest-triangle.png"/>
			</slide>
			<slide>
				<title>Nouns</title>
				<ul>
					<li>Nouns are the names of resources</li>
					<ul>
						<li>in most designs, these names will be URIs</li>
						<li>URI design is a very important part of a REST-based system design</li>
					</ul>
					<li>Everything of interest should be named</li>
					<ul>
						<li>by supporting well-designed names, applications can talk about named things</li>
						<li>new operations and representations can be introduced</li>
					</ul>
					<li>Separating nouns from verbs and representations improves extensibility</li>
					<ul>
						<li>applications might still work with resources without being able to process them</li>
						<li>introducing new operations on the Web does not break the Web</li>
						<li>introducing new content types on the Web does not break the Web</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Verbs</title>
				<ul>
					<li>Operations which can be applied to resources</li>
					<li>The core idea of REST is to use <em>universal verbs</em> only</li>
					<ul>
						<li>universal verbs can be applied to all nouns</li>
					</ul>
					<li>For most applications, HTTP's basic methods are sufficient</li>
					<ul>
						<li><http>GET</http>: Fetching a resource (there must be no side-effects)</li>
						<li><http>PUT</http>: Transfers a resource to a server (overwriting if there already is one)</li>
						<li><http>POST</http>: Adds to an existing resource on the server</li>
						<li><http>DELETE</http>: Discards a resource (its name cannot be used anymore)</li>
					</ul>
					<li>Corresponding to the most popular basic database operations</li>
					<ul>
						<li>CRUD: Create, Read, Update, Delete</li>
					</ul>
				</ul>
			</slide>
			<slide id="http-post">
				<title><http>POST</http>ing</title>
				<ul>
					<li><http>POST</http> adds instead of an overwriting update</li>
					<li><http>POST</http> can have different effects</li>
					<ul>
						<li>by <http>POST</http>ing, state is changed and a new resource is created</li>
						<li>by <http>POST</http>ing, only the existing resource is changed</li>
						<li>the server signals the difference using HTTP responses (<http>200 OK</http> or <http>201 Created</http>)</li>
					</ul>
					<li>This is a <em>design choice</em></li>
					<ul>
						<li>if the added information needs to be accessible individually, create a new resource</li>
						<li>for changes of an existing resource, no new resource has to be created</li>
					</ul>
					<li>Make sure that resources are navigable using URIs</li>
					<ul>
						<li>if appropriate, a relationship can be represented in the resource format</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Content Types</title>
				<ul>
					<li>Representations should be machine-processable</li>
					<ul>
						<li>they don't have to, they may be opaque to applications</li>
						<li>in many cases, machine-processable representations are advantageous</li>
					</ul>
					<li>Resources are abstractions, REST passes representations around</li>
					<ul>
						<li>resources can have various representations (i.e., content types)</li>
						<li>clients can request content types they are interested in</li>
					</ul>
					<li>Adding or changing content types does not change the system architecture</li>
					<ul>
						<li>different clients and servers support different content types</li>
						<li><link href="http-content-negotiation"/> allows content types to be negotiated dynamically</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>REST vs. Web Services</title>
				<ul>
					<li>REST is a description of the Web's design principles</li>
					<ul>
						<li>it is not something new, it is simply a systematic view of the Web</li>
						<li>REST's claim is to be able to learn from the Web's success</li>
					</ul>
					<li>Web Services (in their narrow sense) do not build on REST</li>
					<ul>
						<li>they use HTTP as a transport protocol</li>
						<li>they re-create Web functionality through additional specifications (WS-*)</li>
						<li>they have been built by programmers using a top-down approach</li>
					</ul>
					<li>REST and Web Services have different design approaches</li>
					<ul>
						<li>REST starts at the resources and takes everything from there</li>
						<li>Web Services focus on messages, which in most cases are operations</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part id="rest-implementation">
			<title>REST Implementation</title>
			<slide>
				<title>REST Technologies</title>
				<ul>
					<li>REST is not tied to a particular set of technologies</li>
					<ul>
						<li><link href="rest-uri"/> are the most common choice for nouns</li>
						<li><link href="rest-http"/> methods are the most common choice for verbs</li>
						<li><link href="rest-xml"/> is the most common choice for content types</li>
					</ul>
					<li>Choosing other technologies should have a very good reason</li>
					<ul>
						<li>building a REST system should make it open and accessible</li>
						<li>technology choices are as important as architectural choices</li>
					</ul>
				</ul>
			</slide>
			<slide id="rest-uri">
				<title>URIs</title>
				<ul>
					<li>REST requires a lot of URI design</li>
					<ul>
						<li>instead of being generated as a side-effect, they are the core of the system</li>
					</ul>
					<li>Designing URIs and starting from them is a new way of thinking</li>
					<ul>
						<li>URIs are much more powerful than just being an address of a Web page</li>
					</ul>
					<li>URIs are names for concepts</li>
					<ul>
						<li>concepts are never transmitted, only their representation</li>
						<li>having to focus on concepts rather than representations is helpful</li>
					</ul>
				</ul>
			</slide>
			<slide id="rest-http">
				<title>HTTP</title>
				<ul>
					<li>HTTP is the most successful RESTful protocol</li>
					<ul>
						<li>HTTP's author Roy Fielding coined the term <q>REST</q> in his <a href="http://dret.net/biblio/reference/fie00">Ph.D. thesis</a></li>
					</ul>
					<li>HTTP should be regarded as an <q>application-level protocol</q></li>
					<ul>
						<li>Web Service technologies use HTTP as a transport protocol</li>
						<li>HTTP has much more to offer than a firewall-penetrating pipe</li>
					</ul>
					<li>Web infrastructure is built around proper HTTP usage</li>
					<ul>
						<li>caching is built into HTTP and caches optimize the Web transparently</li>
						<li>authentication can be done using HTTP's authentication methods</li>
						<li>secure data transfer can be done using <link href="https"/></li>
					</ul>
				</ul>
			</slide>
			<slide id="rest-xml">
				<title>XML</title>
				<ul>
					<li>URI-identified resources are abstract concepts</li>
					<ul>
						<li>for machine-based processing, XML is a good representation</li>
						<li>for human-oriented interactions, HTML probably is a better choice</li>
					</ul>
					<li>Connections to other resources must be done by URI</li>
					<ul>
						<li>XML does not make built-in assumptions about identifiers</li>
						<li>but it does support URIs, for example with <em>XInclude</em> and <em>XML Base</em></li>
						<li>RESTful applications are about navigating a Web of URI-identified resources</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part>
			<title>Conclusions</title>
			<slide>
				<title>Better Services</title>
				<ul>
					<li>REST is an architectural style</li>
					<ul>
						<li>URI/HTTP/HTML/XML may be replaced</li>
						<li>the general principle of resource-based interaction remains valid</li>
					</ul>
					<li>RESTful system designs can create better systems</li>
					<ul>
						<li>a little bit more design effort in the beginning</li>
						<li>a lot less headaches later</li>
					</ul>
					<li>SOA often are not really RESTful</li>
					<ul>
						<li>SOA often focuses on operations</li>
						<li>REST focuses on resources</li>
					</ul>
					<li>RESTful design is a good starting point for OO implementations</li>
				</ul>
			</slide>
		</part>
    </presentation>
    <presentation id="unicode">
        <title short="Unicode">Character Set Issues &amp; Unicode</title>
        <date>2007-09-25</date>
        <toc class="resources"><a href="http://unicode.org/" title="Unicode Web Site">Unicode</a>&#160;· <a href="http://homepages.cwi.nl/~dik/english/codes/stand.html" title="History of Character Sets">History</a></toc>
        <toc class="abstract">Every character-based document is based on some model of which characters are available, and how they are encoded. <em>Unicode</em> is the most popular character set today and provides a variety of encoding schemes, each of them being a <em>Unicode Transformation Format (UTF)</em>. In addition to character sets and encodings, other issues relevant when dealing with characters are <em>transcoding</em> and <em>normalization</em>, which deal with the problems arising when using different character encodings or different encodings of particular characters.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
        <part id="characters">
			<title>Characters</title>
			<slide>
				<title>Characters and Computers</title>
				<ul>
					<li><em>American Standard Code for Information Interchange (ASCII)</em></li>
					<ul>
						<li>for the first time a basic set of characters had a universally accepted encoding</li>
						<li>many Internet protocols (such as <a href="../services-fall06/web1#(12)">HTTP</a>) encode their information in ASCII commands</li>
					</ul>
					<li>ASCII is a very limited repertoire of characters</li>
					<ul>
						<li>basic ASCII contains 128 characters (7 bit) with a number of control chars</li>
						<li>no variants of characters (german umlauts, french accents) are supported</li>
						<li>various code pages extending ASCII to 8 bit exist and are hard to distinguish</li>
					</ul>
					<li><em>Character</em> is not a trivial concept when regarded globally</li>
					<ul>
						<li>european languages all have writing systems based on a small number of <q>atoms</q></li>
						<li>other languages and writing systems have vastly different ideas of <q>language atoms</q></li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Characters</title>
				<blockquote>Character. (1) The smallest component of written language that has semantic value; refers to the abstract meaning and/or shape […]</blockquote>
				<p class="quotenote"><a href="http://dret.net/biblio/reference/unicode4"><em>The Unicode Standard, Version 4.0</em>, Addison-Wesley, 2003</a></p>
				<ul>
					<li>The alphabetic approach is only one of several possibilities</li>
					<ul>
						<li>A character in <em>Japanese hiragana and katakana scripts</em> corresponds to a syllable (usually a combination of consonant plus vowel)</li>
						<li><em>Korean Hangul</em> combines symbols for individual sounds of the language into square blocks, each of which represents a syllable; depending on the user and the application, either the individual symbols or the syllabic clusters can be considered to be characters</li>
						<li>In <em>Indic scripts</em> each consonant letter carries an inherent vowel that is eliminated or replaced using semi-regular or irregular ways to combine consonants and vowels into clusters; depending on the user and the application, either individual consonants or vowels, or the consonant or consonant-vowel clusters can be perceived as characters</li>
						<li><em>Arabic and Hebrew vowel sounds</em> are typically not written at all; when they are written they are indicated by the use of combining marks placed above and below the consonantal letters</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Glyphs</title>
				<blockquote>[A Glyph is] a recognizable abstract graphic symbol which is independent of a specific design.</blockquote>
				<p class="quotenote"><a href="http://dret.net/biblio/reference/iso9541"><em>ISO/IEC 9541:1991, Information Technology – Font Information Interchange</em></a></p>
				<ul>
					<li><em>Visual rendering</em> introduces the notion of a glyph.</li>
					<li>There is <em>not</em> a one-to-one correspondence between characters and glyphs</li>
					<ul>
						<li>A single character can be represented by multiple glyphs (each glyph is then part of the representation of that character); these glyphs may be physically separated from one another</li>
						<li>A single glyph may represent a sequence of characters (this is the case with ligatures, among others)</li>
						<li>A character may be rendered with very different glyphs depending on the context</li>
						<li>A single glyph may represent different characters (e.g. capital Latin A, capital Greek A and capital Cyrillic A)</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part id="charactersets">
			<title>Character Sets</title>
			<slide>
				<title>History of Character Sets</title>
				<ul>
					<li>Text documents need ways to represent characters</li>
					<ul>
						<li>computers handle bits, not characters</li>
						<li>to handle characters, computers need a mapping from characters to bits</li>
					</ul>
					<li>For a long time, computers were doing their work in a very isolated way</li>
					<ul>
						<li><q>I think there is a world market for maybe five computers.</q> (<a href="http://en.wikipedia.org/wiki/Thomas_J._Watson#Famous_misquote">¬ T. J. Watson</a>)</li>
					</ul>
					<li>With more computers being used, more data is exchanged between computers</li>
					<li><em>Data rot</em> happens on all levels (media, formats, applications)</li>
					<li>Standardization of character sets started in the 60's</li>
					<ul>
						<li>ASCII was the first generally accepted character set</li>
						<li>EBCDIC was invented and marketed by IBM (and a terribly designed character encoding)</li>
						<li>ISO 8859 was the first attempt to better support character sets beyond ASCII</li>
						<li><em>asian scripts</em> were always a problem because of the number of characters they need</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>ASCII 1963</title>
				<img style="width : 90% ; margin : 2% ; " src="ascii-1963.gif" title="ASCII 1963"/>
			</slide>
			<slide>
				<title>ASCII 1965</title>
				<img style="width : 90% ; margin : 2% ; " src="ascii-1965.gif" title="ASCII 1965"/>
			</slide>
			<slide>
				<title>ASCII 1967</title>
				<img style="width : 90% ; margin : 2% ; " src="ascii-1967.gif" title="ASCII 1967"/>
			</slide>
			<slide>
				<title>EBCDIC</title>
				<table width="95%">
					<tr>
						<td>
							<img style="width : 90% ; margin : 2% ; " src="ebcdic.gif" title="EBCDIC"/>
							<br/>
							<p style="text-align : center">EBCDIC (1964)</p>
						</td>
						<td>
							<img style="width : 90% ; margin : 2% ; " src="ebcdic-augmented.gif" title="Augmented EBCDIC"/>
							<br/>
							<p style="text-align : center">Augmented EBCDIC</p>
						</td>
					</tr>
				</table>
			</slide>
			<slide>
				<title>Beyond ASCII</title>
				<ul>
					<li>ASCII is called ASCII for a reason</li>
					<ul>
						<li>it works well for english-speaking countries</li>
						<li>the majority of other languages cannot be represented</li>
					</ul>
					<li>Character sets and the 8 bit computer start to collide</li>
					<ul>
						<li>ASCII is very convenient because characters and bytes correspond 1:1</li>
						<li>every character set expanding ASCII will make this more complicated</li>
						<li>complications can occur within and/or outside of the character set</li>
					</ul>
					<li>Introducing a character set beyond 8 bit is a fundamental change</li>
					<ul>
						<li>dealing with and counting bytes is a seductively simple idea</li>
					</ul>
					<li>Introducing several 8 bit character sets saves the 8 bit world</li>
					<ul>
						<li>by introducing several character sets, each of them can remain 8 bit</li>
						<li>the complexity has now been shifted to the handling of various character sets</li>
					</ul>
				</ul>
			</slide>
			<slide id="iso8859">
				<title>ISO 8859</title>
				<ul>
					<li>A <em>family of character sets</em> rather that a single character set</li>
					<ul>
						<li>each ISO 8859 family member is an 8 bit character set (256 characters)</li>
						<li>the lower half (128 characters) are always the same (ASCII)</li>
						<li>the upper half is supporting different user groups and changes between versions</li>
					</ul>
					<li>ISO 8859 files cannot be identified by inspection</li>
					<ul>
						<li>ASCII characters can always be safely interpreted (identical on all ISO 8859 code pages)</li>
						<li>the upper half can only be interpreted if the code page is well-known</li>
					</ul>
					<li>ISO 8859 environments must carefully track the code pages being used</li>
					<ul>
						<li>failure to do so results in misinterpretation of characters</li>
					</ul>
					<listing src="iso8859-15.txt" encoding="ISO-8859-15" line="3-3" title='iso8859-15.txt included with encoding="ISO-8859-15"'/>
					<listing src="iso8859-15.txt" encoding="ISO-8859-1" line="3-3" title='iso8859-15.txt included with encoding="ISO-8859-1"'/>
				</ul>
			</slide>
			<slide>
				<title>ISO 8859-1 (Latin-1) &amp; ISO 8859-2 (Latin-2)</title>
				<table width="95%">
					<tr>
						<td>
							<img style="width : 90% ; margin : 2% ; " src="iso-8859-1.gif" title="ISO 8859-1 (Latin-1)"/>
							<br/>
							<p style="text-align : center">Latin-1 (Western European)</p>
						</td>
						<td>
							<img style="width : 90% ; margin : 2% ; " src="iso-8859-2.gif" title="ISO 8859-2 (Latin-2)"/>
							<br/>
							<p style="text-align : center">Latin-2 (Central European)</p>
						</td>
					</tr>
				</table>
			</slide>
			<slide>
				<title>ISO 8859-4 (Latin-4) &amp; ISO 8859-5 (Cyrillic)</title>
				<table width="95%">
					<tr>
						<td>
							<img style="width : 90% ; margin : 2% ; " src="iso-8859-4.gif" title="ISO 8859-4 (Latin-4)"/>
							<br/>
							<p style="text-align : center">Latin-4 (North European)</p>
						</td>
						<td>
							<img style="width : 90% ; margin : 2% ; " src="iso-8859-5.gif" title="ISO 8859-5 (Cyrillic)"/>
							<br/>
							<p style="text-align : center">Cyrillic</p>
						</td>
					</tr>
				</table>
			</slide>
			<slide>
				<title>ISO 8859-7 (Greek) &amp; ISO 8859-15 (Latin-9)</title>
				<table width="95%">
					<tr>
						<td>
							<img style="width : 90% ; margin : 2% ; " src="iso-8859-7.gif" title="ISO 8859-7 (Greek)"/>
							<br/>
							<p style="text-align : center">Greek</p>
						</td>
						<td>
							<img style="width : 90% ; margin : 2% ; " src="iso-8859-15.gif" title="ISO 8859-15 (Latin-9)"/>
							<br/>
							<p style="text-align : center">Latin-9</p>
						</td>
					</tr>
				</table>
			</slide>
		</part>
		<part id="unicode-basics">
			<title>Unicode Basics</title>
			<slide>
				<title>ISO 8859 Problems</title>
				<ul>
					<li>One document can only contain characters from one character set</li>
					<ul>
						<li>mixing characters from different sets is impossible without additional mechanisms</li>
					</ul>
					<listing src="currency-euro.txt"/>
					<li>An increasing number of character sets does not make life easier</li>
					<ul>
						<li>in particular, if they sometime differ only slightly (e.g., Latin-1 vs. Latin-9)</li>
					</ul>
					<li>For bigger character sets, the 8 bit approach is not working at all</li>
					<ul>
						<li>the ISO 8859 approach allows only 128 special characters (the lower half is ASCII)</li>
					</ul>
					<li>ISO 8859 is as good as it gets with 8 bit</li>
					<ul>
						<li>to improve this approach, the 8 bit philosophy must be abandoned</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Unicode</title>
				<ul>
					<li>Generalization takes characters beyond one and even two bytes</li>
					<ul>
						<li>Unicode has been designed to cover all characters of the world</li>
						<li>Unicode recently added its 100'000<sup>th</sup> character</li>
						<li>for handling this character set, a more structured approach is required</li>
					</ul>
					<li>Unicode cleanly separates various conceptual steps</li>
					<ul>
						<li>characters are collected and are then part of the <em>character repertoire</em></li>
						<li>characters are then identified by a unique <em>code point</em> (written as <code>U+0041</code>)</li>
						<li>a <em>Character Encoding Scheme (CES)</em> then maps the <em>Coded Character Set (CCS)</em> based on a <em>Character Encoding Form (CEF)</em></li>
					</ul>
					<li><q><a href="../xml-fall07/basics#(6)">XML is ASCII for the 21<sup>st</sup> century</a></q></li>
					<ul>
						<li>purists sometimes consider Unicode too big or dangerous</li>
						<li>Unicode is well-established and is necessary in a globalized economy</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Unicode Character Count</title>
				<ul>
					<li>Unicode has the ability to encode 17 × 2<sup>16</sup> = 1'114'112 characters</li>
					<ul>
						<li>this means that currently ~10% of the available space is used</li>
					</ul>
					<li>Characters are organized into 17 <q>planes</q> of 2<sup>16</sup> = 65'536 characters</li>
					<li>Planes are numbered from <q>0</q> to <q>16</q></li>
					<li>Plane 0 is the <em>Basic Multilingual Plane (BMP)</em></li>
					<ul>
						<li>all characters which in practical use today are part of the BMP (well, <a href="http://www.tlg.uci.edu/~opoudjis/unicode/unicode_astral.html">almost …</a>)</li>
					</ul>
					<li>Planes beyond the BMP contain rare and historic characters</li>
					<ul>
						<li><q><a href="http://unicode.org/charts/PDF/U10300.pdf">Old Italic</a></q>, <q><a href="http://unicode.org/charts/PDF/U10400.pdf">Deseret</a></q>, <q><a href="http://unicode.org/charts/PDF/U1D000.pdf">Byzantine Musical Symbols</a></q></li>
						<li>most space within these <q>astral planes</q> is empty</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>BMP Structure</title>
				<table style="height : 80% ;  font-size : smaller ; ">
					<tr>
						<td width="45%">
							<img width="100%" src="bmp.png"/>
							<br/>
							<p>Roadmap of Unicode BMP. Each numbered box represents 256 characters. (Source: <a href="http://en.wikipedia.org/wiki/Basic_Multilingual_Plane">Wikipedia</a>)</p>
						</td>
						<td width="55%">
							<ul>
								<li><span style="background-color: #000000"><font color="white">&#160;Black&#160;</font></span> = Latin scripts and symbols</li>
								<li><span style="background-color: #00C0FF">&#160;Light Blue&#160;</span> = Linguistic scripts</li>
								<li><span style="background-color: #0000FF"><font color="white">&#160;Blue&#160;</font></span> = Other European scripts</li>
								<li><span style="background-color: #FF8000">&#160;Orange&#160;</span> = Middle Eastern and SW Asian scripts</li>
								<li><span style="background-color: #FFCC00">&#160;Light Orange&#160;</span> = African scripts</li>
								<li><span style="background-color: #00C000">&#160;Green&#160;</span> = South Asian scripts</li>
								<li><span style="background-color: #8000FF"><font color="white">&#160;Purple&#160;</font></span> = Southeast Asian scripts</li>
								<li><span style="background-color: #FF0000">&#160;Red&#160;</span> = East Asian scripts</li>
								<li><span style="background-color: #FF8080">&#160;Light Red&#160;</span> = Unified CJK Han</li>
								<li><span style="background-color: #FFFF00">&#160;Yellow&#160;</span> = Canadian Aboriginal scripts</li>
								<li><span style="background-color: #FF00FF">&#160;Magenta&#160;</span> = Symbols</li>
								<li><span style="background-color: #808080"><font color="white">&#160;Dark Grey&#160;</font></span> = Diacritics</li>
								<li><span style="background-color: #C0C0C0">&#160;Light Grey&#160;</span> = UTF-16 surrogates and private use</li>
								<li><span style="background-color: #00FFFF">&#160;Cyan&#160;</span> = Miscellaneous characters</li>
								<li>&#160;White&#160; = Unused</li>
							</ul>
						</td>
					</tr>
				</table>
			</slide>
			<slide>
				<title>Unicode Encodings</title>
				<table style="margin : 5% ; width : 85% ; "> 
					<tr><th/><th>A</th><th>א</th><th>好</th><th><img src="U+233B4.gif" style="height : 1em ; "/></th></tr> 
					<tr><th>Code point</th><td>U+0041</td><td>U+05D0</td><td>U+597D</td><td>U+233B4</td></tr> 
					<tr><th>UTF-8</th><td>41</td><td>D7 90</td><td>E5 A5 BD</td><td>F0 A3 8E B4</td></tr> 
					<tr><th>UTF-16</th><td>00 41</td><td>05 D0</td><td>59 7D</td><td>D8 4C DF B4</td></tr> 
					<tr><th>UTF-32</th><td>00 00 00 41</td><td>00 00 05 D0</td><td>00 00 59 7D</td><td>00 02 33 B4</td></tr> 
				</table>
			</slide>
			<slide>
				<title>UTF-8</title>
				<ul>
					<li>UTF-8 is one of the two standardized encodings for XML</li>
					<ul>
						<li>every ASCII document by definition is a UTF-8 document</li>
						<li>UTF-8 must be supported by every XML implementation</li>
					</ul>
					<li>UTF-8 is not trivial, but it is widely supported and easy to implement</li>
					<ul>
						<li>there is no 1:1 correspondence between bytes and characters</li>
						<li>each Unicode character is encoded by 1-6 bytes</li>
						<li>UTF-8 is good for europeans (1 byte per ASCII character)</li>
					</ul>
					<li>Non-Unicode documents must be <em>transcoded</em> to UTF-8</li>
					<ul>
						<li>keeping track of resource character encodings is a good idea</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Other UTFs</title>
				<ul>
					<li>UTF-16 stores every character as 2 or more bytes</li>
					<ul>
						<li>BMP characters are stored as 2 bytes</li>
						<li>astral plane characters are stored as 4 bytes</li>
						<li>UTF-16 is the other encoding (in addition to UTF-8) required by XML</li>
					</ul>
					<li>UTF-32 stores every character as 4 bytes</li>
					<ul>
						<li>very simple and very inefficient (ASCII text volume increases by 300%)</li>
					</ul>
					<li>Multi-byte formats introduce the problem of <em>byte order</em></li>
					<ul>
						<li>UTF-16/32BE and UTF-16/32LE are stored with guaranteed endian</li>
						<li>UTF-16/32 may use a <em>Byte Order Mark (BOM)</em> (U+FEFF) to detect the endian</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Character Set Identification</title>
				<ul>
					<li>HTTP, XML, and HTML support character set identification</li>
					<ul>
						<li><a href="../services-fall06/web1#(12)">HTTP</a> supports the <code>Content-Type</code> <a href="../services-fall06/web1#(17)">header field</a></li>
						<pre>Content-Type: text/html; charset=utf-8</pre>
						<li>XML encodes the character set <a href="../xml-fall07/basics#(8)">in the XML declaration</a></li>
						<pre>&lt;?xml version="1.0" encoding="utf-8"?></pre>
						<li>HTML supports the <elem>meta</elem> element in the document's <elem>head</elem></li>
						<pre>&lt;meta http-equiv="Content-Type" content="text/html;charset=utf-8"></pre>
					</ul>
					<li>Different identifications serve different purposes</li>
					<li><em>Conflicting identifications</em> are a sign of management problems</li>
				</ul>
			</slide>
        </part>
        <part>
			<title>Normalization and Transcoding</title>
			<slide>
				<title>Unicode is Complex</title>
				<ul>
					<li>Many languages have characters which are composed</li>
					<ul>
						<li>german umlauts are vowels with a double dot</li>
						<li>french accents and the cedilla are also added to <q>regular</q> characters</li>
					</ul>
					<li>Unicode contains composed as well as composing characters</li>
					<ul>
						<li>for most languages, composed characters are considered to be regular characters</li>
						<li>in some circumstances, it might be required to compose a character out of a base and a <em>diacritical mark</em></li>
						<li>as a result, the question arises how to define the equality of these variants</li>
					</ul>
					<li>Unicode defines <em>normal forms</em> which prescribe one variant</li>
					<ul>
						<li>a complex field with different concepts of equivalence (<em>canonical</em> and <em>compatibility</em>)</li>
						<li>based on the equivalence forms, there are four <a href="http://www.unicode.org/reports/tr15/">normalization forms</a></li>
					</ul>
				</ul>
				<listing src="francais.xml" line="2-2" title="Unnormalized Unicode"/>
				<listing src="francais.xml" line="2-2" encoding="ISO-8859-1" title='Unnormalized UTF-8 with encoding="ISO-8859-1"'/>
			</slide>
			<slide>
				<title>Normalization Examples</title>
				<img style="width : 86% ; margin : 4% ; " src="unicode-normalization" title="Compatibility Composites"/>
			</slide>
			<slide>
				<title>Transcoding</title>
				<ul>
					<li>Handling Unicode in an unconstrained environment is not easy</li>
					<ul>
						<li>Unicode's size and variability make character processing harder then it used to be</li>
						<li>for some applications with limited character need, this might be too much</li>
					</ul>
					<li>In all text-based environments, well-defined rules must be defined for</li>
					<ol>
						<li>the encoding of documents (maybe if variants, such as Unicode normalization forms)</li>
						<li>accepted incoming encodings and how they are mapped to the internal encoding</li>
						<li>available outgoing encodings and how they can be requested and will be generated</li>
					</ol>
					<li><em>Transcoding</em> is the activity of changing the encoding of data</li>
					<ul>
						<li>ideally, transcoding should be lossless and round-trip proof</li>
						<li>in any scenario with non-trivial encodings, this is not an easy goal</li>
						<li>even staying with one encoding can be a problem (if there are variations allowed)</li>
					</ul>
					<li>Transcoding is essential for maintaining data quality</li>
				</ul>
			</slide>
        </part>
        <part>
			<title>Conclusions</title>
			<slide>
				<title>Text is Complex</title>
				<ul>
					<li>Even unstructured text is complex when generalizing the concept</li>
					<li>Most application have parts where they manage text-based data</li>
					<li>For simple applications, simple character sets may be appropriate</li>
					<li>Unicode provides a large character repertoire, but at a certain cost</li>
					<li>Handling text encodings must be well-defined</li>
					<ul>
						<li>this is not trivial when thinking about a general text-based application</li>
						<li>once rule have been defined and documented, things usually go well</li>
					</ul>
				</ul>
			</slide>
        </part>
    </presentation>
    <presentation id="mime">
        <title short="Media Types">Multipurpose Internet Mail Extensions (MIME) Types</title>
        <date>2007-09-27</date>
        <toc class="reading"><a href="http://www.w3.org/2001/tag/doc/mime-respect" title="Authoritative Metadata">MIME Respect</a></toc>
        <toc class="resources"><a href="http://dret.net/rfc-index/reference/RFC2046" title="Media types RFC">MIME</a>&#160;· <a href="http://www.iana.org/assignments/media-types/" title="IANA media type registry">Registry</a></toc>
        <toc class="abstract">One of the most important aspect of computer-based communications is the concept of <em>media types</em>, the question what type of information some digital artifact represents, and how it is encoded. The most common standard for this information is the scheme introduced by <em>Multipurpose Internet Mail Extensions (MIME)</em>. Media types can be negotiated by peers communicating through HTTP. Some media types allow <em>fragment identifiers</em>, which allow references to a resource to identify a fragment of the complete resource.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<slide>
			<title>Multipurpose Internet Mail Extensions (MIME)</title>
			<ul>
				<li>Basic e-mail only supports ASCII text messages</li>
				<li>MIME was introduced in 1993 to standardize a more powerful message format</li>
				<ul>
					<li>multiple objects in a single message</li>
					<li>text having unlimited line length or overall length</li>
					<li>character sets other than ASCII, allowing non-English language messages</li>
					<li>binary or application specific files</li>
					<li>images, audio, video and multi-media messages</li>
				</ul>
				<li>Resource types are necessary for every automated action with resources</li>
				<ul>
					<li>Unix started with <code>/etc/mime.types</code>, a list of mappings between extensions and media types</li>
					<li>the Unix <code>file</code> command uses simple fingerprints (specified in <code>/etc/magic</code>)</li>
					<li>double-clicking in GUIs needs a file association (based on the file's type) to work</li>
				</ul>
			</ul>
		</slide>
		<slide>
			<title>Unix File Type Handling</title>
			<listing src="mime.types" line="376-386" title="Rosetta's /etc/mime.types"/>
			<listing src="mime-magic" line="381-392" title="Rosetta's /etc/mime-types"/>
		</slide>
		<slide>
			<title>Windows File Type Handling</title>
			<img style="width : 90% ; margin : 2% ; " src="windows-file-types.png" title="Windows File Type Handling"/>
		</slide>
		<part>
			<title>Media Types and the Web</title>
			<slide>
				<title>Browsers and Resources</title>
				<ul>
					<li>Web browsers retrieve resources and render them</li>
					<ul>
						<li>HTTP can transfer any kind of resource (binary resources must be transfer encoded)</li>
						<li>resource types cannot (and should not) be inferred from the URI</li>
					</ul>
					<li>HTTP combines data transfer, transfer management, and metadata</li>
					<ul>
						<li>basic information about a resource (modification date)</li>
						<li>information describing the resource's type (media type) and content (language)</li>
						<li><link href="http-content-negotiation"/> can be used to request a specific resource variant</li>
					</ul>
					<li>The resource type received may or may not be supported by the browser</li>
					<ul>
						<li><em>built-in support</em> is provided for the core Web resource types (HTML, GIF, JPEG)</li>
						<li><em>plug-in</em> support is an add-on to the browser for popular types (PDF, Flash)</li>
						<li><em>external applications</em> are standalone applications invoked by the browser</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Firefox Media Type Handling</title>
				<img style="width : 90% ; margin : 2% ; " src="firefox-media-types.png" title="Controlling Media Type Handling in Firefox"/>
			</slide>
			<slide>
				<title>Media Type Control in Browsers</title>
				<ul>
					<li>In practice, media type control is less than perfect</li>
					<ul>
						<li>getting control over media types means getting control over your computer</li>
						<li>applications are rarely written in a perfectly well-designed way</li>
					</ul>
					<li>XML is handled very poorly by Firefox</li>
					<ul>
						<li><q>rendering</q> XML is unbelievably slow (and very primitive)</li>
						<li>if the XML has errors (real or imagined by Firefox), there is no way to get to it</li>
						<li>helper applications can be registered, but this is ignored by Firefox</li>
					</ul>
					<li>Competing application suites hijack as many media types as possible</li>
					<ul>
						<li><em>QuickTime</em> and <em>Windows Media Player</em> support the same media types</li>
						<li>installing or updating these packages often changes many media type settings</li>
					</ul>
				</ul>
			</slide>
		</part>
        <part>
			<title>Media Types</title>
			<slide id="mime-content-types">
				<title>Content Types</title>
				<ul>
					<li>MIME splits the word of resource types into <em>Content Types</em> and <em>Subtypes</em></li>
					<ul>
						<li><em>Content types</em> are the main classification of a resource type</li>
						<li><link href="mime-subtypes"/> qualify the format and encoding used for the content</li>
					</ul>
					<li>Content types classify the world of resource type into 8 areas</li>
					<ul>
						<li><mime>audio</mime> for media types representing exclusively audio signals</li>
						<li><mime>image</mime> for any media type representing two-dimensional images</li>
						<li><mime>message</mime> for resources representing e-mail messages</li>
						<li><mime>model</mime> for complex representations of physical objects (very unpopular)</li>
						<li><mime>multipart</mime> for MIME entities containing multiple individual MIME-tagged resources</li>
						<li><mime>text</mime> for mainly textual material (e.g., HTML is considered to be text)</li>
						<li><mime>video</mime> for media types combining moving pictures with audio</li>
						<li><mime>application</mime> for any resource which cannot by classified anywhere else</li>
						<li>(<mime>example</mime> is only used for media type examples, not for real-world resources)</li>
					</ul>
				</ul>
			</slide>
			<slide id="mime-subtypes">
				<title>Subtypes</title>
				<ul>
					<li>Within each content type, many different data formats are in use</li>
					<ul>
						<li>content types only allow a broad classification</li>
						<li>subtypes allow the identification of a specific data format of a resource</li>
					</ul>
					<li>Subtypes are expected to be <link href="mime-registration">registered</link> with the <a href="http://dret.net/glossary/iana" title="Internet Assigned Names Authority">IANA</a></li>
					<ul>
						<li>unregistered subtypes can be used but must have a <mime>x-</mime> prefix</li>
					</ul>
					<li>Additional qualifiers can be used to be more specific</li>
					<ul>
						<li><mime>text/plain</mime> is the media type for plain text files</li>
						<li>plain text files have additional properties such as character encoding and language</li>
						<li><mime>text/plain</mime> can be further qualified to <mime>text/plain; charset=iso-8859-1</mime></li>
						<li>not all qualifications are available as media type (e.g., language is not addressed)</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>What is XML?</title>
				<ul>
					<li>XML can be regarded from various point of view</li>
					<ul>
						<li>XHTML is (almost) identical to HTML and should be regarded as <mime>text</mime></li>
						<li>configuration files are data for some program and should be regarded as <mime>application</mime></li>
						<li>XML schemas can be mixes of these two extreme cases</li>
					</ul>
					<li><a href="http://dret.net/rfc-index/reference/RFC3023">RFC 3023</a> registers a set of XML-related media types</li>
					<ul>
						<li><mime>application/xml</mime> for generic XML usage (data oriented XML)</li>
						<li><mime>text/xml</mime> for textual XML usage (document oriented XML)</li>
						<li><mime>application/xml-dtd</mime> for DTDs (which are not XML documents)</li>
						<li><mime>application/xslt+xml</mime> (proposed) for XSLT stylesheets (<mime>text/css</mime> is defined by <a href="http://dret.net/rfc-index/reference/RFC2318">RFC 2318</a>)</li>
						<li><mime>image/svg+xml</mime> (proposed) for vector graphics using <link href="svg"/></li>
						<li><mime>application/xhtml+xml</mime> is defined by <a href="http://dret.net/rfc-index/reference/RFC3236">RFC 3236</a></li>
						<li>… and a number of other suggestions for future XML media types</li>
					</ul>
				</ul>
			</slide>
			<slide id="mime-registration">
				<title>Media Type Registration</title>
				<ul>
					<li>Media types need to be registered together with a documentation</li>
					<ul>
						<li>this makes sense if it is assumed that registered types should be openly accessible</li>
						<li>this becomes complicated if the types are proprietary and not publicly documented</li>
					</ul>
					<li>It makes sense to register types even if they are not publicly documented</li>
					<ul>
						<li>if a Word document is sent by e-mail it should be opened by the Word application</li>
						<li>IANA registers <q><mime>vnd.</mime></q> prefixed subtypes with less requirements than <q>regular</q> types</li>
						<li>vendor specific types are often undocumented and may change significantly over time</li>
					</ul>
					<li>Using well-defined types makes handling resources more stable</li>
					<ul>
						<li>the IANA registry contains hundreds of types (most of them <mime>application</mime> types)</li>
						<li>when designing applications dealing with various content types, use media types as the foundation</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title><mime>application/msword</mime> Media Type</title>
				<listing src="msword.txt" line="43-63" title="application/msword Media Type Registration" href="http://www.iana.org/assignments/media-types/application/msword"/>
			</slide>
			<part>
				<title>Text Content Types</title>
				<slide id="mime-plaintext">
					<title>Plain Text</title>
					<ul>
						<li><a href="http://dret.net/rfc-index/reference/RFC2046">RFC 2046</a> defines plain text files as a basic media type</li>
						<ul>
							<li>any text file that does not contains structures which are intended for machine-based processing</li>
							<li>even <link href="mime-csv"/> does not count as plain text</li>
						</ul>
						<li>Guessing of character encoding is hard and unreliable and should be avoided</li>
						<ul>
							<li>the character encoding can be specified with an additional parameter: <mime>text/plain; charset=iso-8859-1</mime></li>
							<li>if no such parameter is present, ASCII should abe assumed as the character encoding</li>
						</ul>
						<li>For more specific text subtypes, <a href="http://www.iana.org/assignments/media-types/text/">various other subtypes exist</a></li>
						<ul>
							<li><mime>calendar</mime> for information about calendar entries</li>
							<li><mime>javascript</mime> for JavaScript code (should now be marked as <mime>application/javascript</mime>)</li>
							<li><mime>sgml</mime> and <mime>xml</mime> for text with additional markup</li>
						</ul>
					</ul>
				</slide>
				<slide id="mime-html">
					<title>HTML</title>
					<ul>
						<li><a href="http://dret.net/rfc-index/reference/RFC2854">RFC 2854</a> registers <mime>text/html</mime> for HTML documents</li>
						<ul>
							<li>like <link href="mime-plaintext"/> the character encoding can also be specified as a parameter</li>
							<li>it is not specific for some version of HTML (version information can be found in the HTML document)</li>
						</ul>
						<li><link href="html-fragment-identifiers"/> are also defined by the media type registration</li>
						<li>HTML in many cases needs additional resources to be <q>self-contained</q></li>
						<ul>
							<li>images which are references by <elem>img</elem> elements (maybe external image maps)</li>
							<li>other media referenced by <elem>object</elem> or <elem>applet</elem> (or the deprecated <elem>embed</elem>)</li>
							<li>stylesheets or scripts which are referenced in the document head (they may reference other files …)</li>
							<li>generating a truly self-contained HTML is a rather hard task</li>
						</ul>
						<li>MIME can be used to represent a self-contained <a href="http://dret.net/glossary/mhtml" title="MIME HTML">MHTML</a> (<a href="http://dret.net/rfc-index/reference/RFC2557">RFC 2557</a>)</li>
					</ul>
				</slide>
				<slide id="mime-csv">
					<title short="CSV">Comma-Separated Values (CSV)</title>
					<ul>
						<li><a href="http://dret.net/rfc-index/reference/RFC4180">RFC 4180</a> defines a textual format for <q>spreadsheet data</q></li>
						<li>CSV has been used for a long time, but some of the details were solved differently</li>
						<li>Defining a media type makes it easier for implementations to know what to expect</li>
						<ul>
							<li>the registration not only registers the type, but also defines it</li>
						</ul>
						<li>CSV is not overly complex, but some issues have to be solved</li>
						<ul>
							<li>how to separate lines (CRLF)</li>
							<li>how to end the file (CRLF is allowed but optional)</li>
							<li>are there headers allowed (yes, but they are not marked as such)</li>
							<li>may different lines use different numbers of fields (no)</li>
							<li>are spaces significant (yes)</li>
							<li>are quotes significant (no, they are delimiters, so quotes as values must be escaped)</li>
							<li>how to treat fields with CRLF, commas, or quotes (enclose the value in quotes)</li>
						</ul>
					</ul>
				</slide>
			</part>
			<part>
				<title>Application Content Types</title>
				<slide>
					<title>JSON</title>
					<ul>
						<li><a href="http://dret.net/rfc-index/reference/RFC4627">RFC 4627</a> registers JSON as a media type</li>
						<li>The definition of JSON is derived from ECMAScript's <em>object literals</em></li>
						<li>JSON is a very limited notation intended for simple structures</li>
						<ul>
							<li>it allows the four primitive types <em>strings</em>, <em>numbers</em>, <em>booleans</em>, and <em>null</em></li>
							<li>it allows the two structured types <em>objects</em> (unordered) and <em>arrays</em> (ordered)</li>
						</ul>
						<li>The value of the media type in this case is the clean integration into the Web</li>
						<ul>
							<li>information providers may choose to expose their data in JSON and XML</li>
							<li><link href="http-content-negotiation"/> can be used to specify which representation is preferred</li>
						</ul>
					</ul>
				</slide>
			</part>
			<part>
				<title>Image Content Types</title>
				<slide id="mime-gif">
					<title short="GIF">Graphic Interchange Format (GIF)</title>
					<ul>
						<li><a href="http://dret.net/rfc-index/reference/RFC2046">RFC 2046</a> registers the oldest graphics format on the Web</li>
						<li>GIF was subject of a long patent debate</li>
						<ul>
							<li>the compression technique of GIF (<a href="http://dret.net/glossary/lzw" title="Lempel-Ziv-Welch">LZW</a>) had been patented by Unisys (1983)</li>
							<li>Unisys wanted to get licensing fees from all commercial online uses of GIF</li>
							<li><link href="png"/> was developed as an effort to develop a copyright-free format</li>
							<li>in 1999, Unisys changed its tactics and wanted to collect one-time fees ($5000-$7500) from all users</li>
							<li>all GIF-related LZW expired in 2003/2004, so GIF is freely available now</li>
						</ul>
						<li>GIF's poor features make PNG the better choice anyway</li>
						<ul>
							<li>8 bit color (requires dithering for photographs), binary transparency</li>
							<li>GIF's animation feature is the only thing that is not available in PNG … <img src="running-wolf.gif" style="height : 0.8em"/></li>
						</ul>
					</ul>
				</slide>
				<slide id="mime-jpeg">
					<title short="JPEG">Joint Photographic Experts Group (JPEG)</title>
					<ul>
						<li><a href="http://dret.net/rfc-index/reference/RFC2046">RFC 2046</a> standardizes the second popular image format for the Web</li>
						<li>JPEG has been specifically designed for photographs</li>
						<ul>
							<li>it always is lossy (it cannot preserve the complete information from a random bitmap)</li>
							<li>it uses perception-based compression (for example, color precision is sacrificed for brightness)</li>
						</ul>
					</ul>
					<table style="width : 90% ; margin : 4% ;  font-size : smaller ; ">
						<tr>
							<td align="center">
								<img src="jpeg-average-quality.jpg" title="Average Quality JPEG" href="http://en.wikipedia.org/wiki/JPEG#Photographs"/>
							</td>
							<td align="center">
								<img src="jpeg-low-quality.jpg" title="Low Quality JPEG" href="http://en.wikipedia.org/wiki/JPEG#Photographs"/>
							</td>
							<td align="center">
								<img src="jpeg-lowest-quality.jpg" title="Lowest Quality JPEG" href="http://en.wikipedia.org/wiki/JPEG#Photographs"/>
							</td>
						</tr>
						<tr>
							<th>Q = 50, filesize 15,138 bytes</th>
							<th>Q = 10, filesize 4,787 bytes</th>
							<th>Q = 1, filesize 1,523 bytes</th>
						</tr>
					</table>
				</slide>
				<slide id="mime-png">
					<img src="png-transparency.png" style="float : right ; "/>
					<title short="PNG">Portable Network Graphics (PNG)</title>
					<ul>
						<li>PNG is registered as <mime>image/png</mime> and is the third major image format</li>
						<ul>
							<li>PNG was intended to be a royalty- and copyright-free replacement of <link href="gif">GIF</link></li>
							<li>image formats need to supported by browsers and thus take a long time until they are established</li>
							<li>IE6 implements PNG in a very rudimentary form, IE7 handles PNG correctly</li>
						</ul>
						<li>PNG has some advantages over GIF and JPEG</li>
						<ul>
							<li>lossless, compressed palette, grayscale, or true color images</li>
							<li>8 bit alpha channel for gradual opacity (blending into the background)</li>
						</ul>
						<li>JPEG still is the preferred format for photographic pictures</li>
						<li>GIF still is the preferred format for animated images</li>
						<ul>
							<li><a href="http://dret.net/glossary/mng" title="Multiple-image Network Graphics">MNG</a> and <a href="http://dret.net/glossary/apng" title="Animated Portable Network Graphics">APNG</a> are two available but not widely supported PNG animation formats</li>
						</ul>
					</ul>
				</slide>
			</part>
        </part>
        <part id="fragment-identifiers">
			<title>Fragment Identifiers</title>
			<slide>
				<title>Identification of Resource Fragments</title>
				<ul>
					<li>URIs identify a resource (based on a scheme and a scheme-specific part)</li>
					<ul>
						<li>URIs do not necessarily identify a specific representation of a resource</li>
						<li>any representation-specific operation needs to look at the resource type</li>
					</ul>
					<li>Fragment identifiers can be used to identify a part of a resource</li>
					<ul>
						<li><code href="http://dret.net/netdret/publications#wil02h">http://dret.net/netdret/publications<span style="color : red">#wil02h</span></code></li>
						<li>fragments are a <em>client side</em> concept (the HTTP GET requests the complete resource)</li>
						<li>if the client supports fragment handling, the identifier is interpreted</li>
					</ul>
					<li>Fragment identifiers and content negotiation have a problematic relationship</li>
					<ul>
						<li>keeping fragment identifiers stable across resource variants may be hard</li>
						<li>nothing in the fragment identifier associates it with a specific resource variant</li>
					</ul>
				</ul>
			</slide>
			<slide id="html-fragment-identifiers">
				<title>HTML Fragment Identifiers</title>
				<ul>
					<li>HTML allows to address named/identified elements in the HTML document</li>
					<ul>
						<li>the first HTML versions required named <code>&lt;a name="frag-id">incoming anchors&lt;/a></code></li>
						<li>newer HTML versions allow <code>&lt;p id="frag-id">every element to have an id&lt;/p></code></li>
						<li>browsers support both ways, but the <xml>id</xml> variant should be preferred</li>
					</ul>
					<li>Only named/identified fragments can be identified</li>
					<ul>
						<li>99.99% of all page authors do not routinely add identifications</li>
						<li>tools may be smarter and take over that task (e.g., <em>Movable Type</em> identifies all relevant elements)</li>
						<li>for most pages on the Web this means users cannot link to most elements in them</li>
					</ul>
					<li>Keeping fragment identifiers stable should be a goal of Web authors</li>
					<ul>
						<li>identify the key fragments (and maybe provide a better UI than <q>view source</q>)</li>
						<li>never change identifiers once they have been assigned</li>
					</ul>
				</ul>
			</slide>
			<slide id="xml-fragment-identifiers">
				<title>XML Fragment Identifiers</title>
				<ul>
					<li>XPointer is the language which defines XML fragment identifiers</li>
					<ul>
						<li>XPointer's history and success is even worse than XLink's</li>
						<li>the interesting part was never finished, the easier parts have been finalized</li>
					</ul>
					<li>XPointer supports HTML's approach of <em>identified elements</em></li>
					<ul>
						<li>if there is simply a name after the <q><code>#</code></q>, it is a <em>shorthand</em> and treated like in HTML</li>
						<li>… almost, actually, because IDs in XML are a bit more complicated (<xml>xml:id</xml> or schema-defined)</li>
					</ul>
					<li>XPointer allows <em>child sequences</em> to navigate the document tree</li>
					<ul>
						<li><code>…#element(/1/2)</code> or <code>…#element(intro/3/1)</code></li>
						<li>the nice aspect is that elements without an explicit identification can be identified</li>
						<li>the risky part is that any changes in the document structure may break the XPointer</li>
					</ul>
					<li>XPointer in all its glory (W3C working draft December 2002 …)</li>
					<ul>
						<li>an extension of XPath inheriting all the interesting features of XPath</li>
						<li>adds the concept of <em>range locations</em> between to XPath-identified <em>point locations</em></li>
					</ul>
				</ul>
			</slide>
        </part>
        <part>
			<title>Conclusions</title>
			<slide>
				<title>Know Your Resources</title>
				<ul>
					<li>Handling Web resources and technologies requires a common vocabulary</li>
					<li>Media types are a useful vocabulary for identifying resource types</li>
					<li>Fragment identifiers add some complexity, in particular for resource variants</li>
				</ul>
			</slide>
		</part>
	</presentation>
	<presentation id="html">
        <title short="HTML">Hypertext Markup Language (HTML)</title>
        <date>2007-10-02</date>
        <toc class="resources"><a href="http://www.w3.org/TR/html401/" title="W3C HTML Spec">HTML</a>&#160;· <a href="http://www.w3.org/TR/xhtml1/" title="W3C XHTML Spec">XHTML</a>&#160;· <a href="http://validator.w3.org/" title="W3C HTML Validator">Validator</a></toc>
        <toc class="abstract">The <em>Hypertext Markup Language (HTML)</em> is the most important content type on the Web. Even though it is primarily intended for humans (by presenting formatted pages of textual content), it also has facets that are important for machine-based processing. HTML can be use in a variety of ways, and this lecture looks at some of the important rules that should be observed when creating HTML, for example how to use HTML markup in general and how to create accessible forms.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<slide>
			<title>HTML and WYSIWYG</title>
			<ul>
				<li>Thinking of HTML as a page-description language is wrong</li>
				<li>HTML has been designed as a structure-description language</li>
				<li>Even a lot of <link href="css"/> style information does not change this</li>
				<ul>
					<li>different available fonts</li>
					<li>fonts with the same family name but different metrics</li>
					<li>different hyphenation algorithms</li>
					<li>hyphenation setting defaults</li>
					<li>hyphenation dictionaries</li>
					<li>different size spaces</li>
					<li>different line-breaking algorithms</li>
					<li>different widow/orphan/keeptogether rules</li>
				</ul>
				<li>HTML authoring is not the same as typesetting documents</li>
			</ul>
		</slide>
		<slide>
			<title>Layout Engine Usage</title>
			<img style="width : 90% ; margin : 2% ; " src="layout-engines.png" title="Usage share of Layout Engines" href="http://en.wikipedia.org/wiki/Usage_share_of_web_browsers"/>
		</slide>
        <part>
			<title>HTML and Structure</title>
			<slide id="html-containers">
				<title>All-Purpose Elements</title>
				<ul>
					<li>HTML elements are supposed to convey structural semantics</li>
					<ul>
						<li><a href="http://www.w3.org/TR/html4/struct/lists.html">lists</a> are available in various flavors (<htmel>ul</htmel>, <htmel>ol</htmel>, <htmel>dl</htmel>)</li>
						<li>various <a href="http://www.w3.org/TR/html4/struct/text.html#h-9.2.1">phrase markup elements</a> are available (<htmel>em</htmel>, <htmel>strong</htmel>, <htmel>dfn</htmel>, <htmel>code</htmel>, <htmel>samp</htmel>, <htmel>kbd</htmel>, <htmel>var</htmel>, <htmel>cite</htmel>, <htmel>abbr</htmel>, <htmel>acronym</htmel>)</li>
						<li>various <a href="http://www.w3.org/TR/html4/struct/global.html#h-7.5.5">levels of headings</a> can be used (<htmel>h1</htmel>-<htmel>h6</htmel>)</li>
					</ul>
					<li>HTML content should represent structural information</li>
					<ul>
						<li>not all content can be mapped to HTML elements</li>
						<li>in many cases HTML elements are available (there are even <a href="http://www.w3.org/TR/html4/struct/text.html#h-9.4">diff elements</a>)</li>
					</ul>
					<li>HTML also has <a href="http://www.w3.org/TR/html4/struct/global.html#h-7.5.4">all-purpose elements</a></li>
					<ul>
						<li>these elements have no semantics and are just containers</li>
						<li><htmel>span</htmel> is used as an inline container</li>
						<li><htmel>div</htmel> is used as a block container</li>
						<li>all-purpose elements should only be used if no HTML element is available</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Retain Content Structures</title>
				<ul>
					<li>HTML should represent content structures</li>
					<ul>
						<li>CSS can be used to tweak the formatting (if required)</li>
					</ul>
					<li>Rich content should be mapped to rich Web pages</li>
					<ul>
						<li>use HTML elements if available</li>
						<li><link href="css-classes">augment HTML elements with CSS classes</link> for more specific semantics</li>
						<li>use <link href="microformats"/> for capturing more semantics</li>
					</ul>
					<li>HTML is just one possible representation of a resource</li>
					<ul>
						<li>the data model of resources should not be limited by HTML</li>
						<li>richer representations may become available in the future</li>
						<li>why are there so few Web pages with <uri>tel:</uri> URIs?</li>
					</ul>
				</ul>
			</slide>
        </part>
		<part id="forms">
			<title>HTML Forms</title>
			<slide>
				<title>HTTP Web Services</title>
				<ul>
					<li>Services can be provided through URI/HTTP</li>
					<ul>
						<li>URI-based services need input as a <link href="uri-query">query string</link></li>
						<li>the question is how the user gets information into the URI</li>
					</ul>
					<li>HTML forms provide an interface for assembling query strings</li>
					<ul>
						<li>users fill out a form providing several fields</li>
						<li>the browser submits the entered information by HTTP to a URI</li>
						<li>the result of the request is displayed to the user</li>
					</ul>
					<li>HTTP has to different methods for submitting data</li>
					<ul>
						<li><code><link href="form-get">GET</link></code> encodes the data as a URI query string</li>
						<li><code><link href="form-post">POST</link></code> encodes the data as HTTP request entity</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Forms Mechanics</title>
				<ul>
					<li>HTML forms are normal Web pages (using form elements)</li>
					<li>The process receiving the form data produces a result page</li>
				</ul>
				<img style="width : 90% ; margin : 2% ; " src="form-mechanics.png"/>
			</slide>
			<slide>
				<title>Forms Markup</title>
				<ul>
					<li>All form elements must be inside a <elem>form</elem> element</li>
					<ul>
						<li>specifies the URI for submitting the form values (<xml>action="URI"</xml>)</li>
						<li>specifies the method for submitting the form values (<xml>method="<link href="form-get">GET</link>|<link href="form-post">POST</link>"</xml>)</li>
						<li>for <code>POST</code> forms, the <xml>encoding</xml> may be selected</li>
					</ul>
					<li><em>form</em> contains regular HTML markup and form elements</li>
					<ul>
						<li>the regular HTML markup creates the form's layout (table, list, texts)</li>
						<li>the form elements create the controls for acquiring input data</li>
					</ul>
					<li>Each <elem>form</elem> should have a <em>submit button</em></li>
					<ul>
						<li>when pressing this button, the form values are sent to the <xml>action</xml> URI</li>
						<li>without such a button, the form values cannot be submitted</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Forms Elements (User View)</title>
				<ul>
					<li>HTML provides a small set of form controls</li>
					<li>Sufficient for a many applications</li>
				</ul>
				<hr/>
				<form action="http://stevex.net/dump.php" method="POST" enctype="multipart/form-data">
					<table>
						<tr><td valign="top" align="right">Text:</td><td><input type="text" name="text" value="text input"/></td></tr>
						<tr><td valign="top" align="right">Password:</td><td><input type="password" name="password" value="hidden text"/></td></tr>
						<tr><td valign="top" align="right">Checkbox:</td><td><input type="checkbox" name="check" value="1"/> <input type="checkbox" name="check" value="2"/> <input type="checkbox" name="check" value="3"/></td></tr>
						<tr><td valign="top" align="right">Radio Button:</td><td><input type="radio" name="radio" value="1"/> <input type="radio" name="radio" value="2"/> <input type="radio" name="radio" value="3"/></td></tr>
						<tr><td valign="top" align="right">Submit:</td><td><input name="submit" type="submit"/></td></tr>
						<tr><td valign="top" align="right">File Upload:</td><td><input name="file" type="file"/></td></tr>
						<tr><td valign="top" align="right">Text Areas:</td><td><textarea name="textarea" rows="2" cols="20"/></td></tr>
						<tr><td valign="top" align="right">Selection:</td><td><select name="select"><option selected="selected">XML</option><option>SGML</option></select></td></tr>
						<tr><td valign="top" align="right">Multiple Selection:</td><td><select name="mselect" multiple="multiple"><option>242</option><option>290-3</option><option>290-13</option></select></td></tr>
					</table>
				</form>
			</slide>
			<slide>
				<title>Forms Elements (Source View)</title>
<pre><![CDATA[<form action="http://stevex.net/dump.php" method="POST" enctype="multipart/form-data"><table>

<tr><td>Text:</td><td><input type="text" name="text" value="text input"/></td></tr>

<tr><td>Password:</td><td><input type="password" name="password" value="hidden text"/></td></tr>

<tr><td>Checkbox:</td><td><input type="checkbox" name="check" value="1"/> <input type="checkbox" name="check" value="2"/> <input type="checkbox" name="check" value="3"/></td></tr>

<tr><td>Radio Button:</td><td><input type="radio" name="radio" value="1"/> <input type="radio" name="radio" value="2"/> <input type="radio" name="radio" value="3"/></td></tr>

<tr><td>Submit:</td><td><input name="submit" type="submit"/></td></tr>

<tr><td>File Upload:</td><td><input name="file" type="file"/></td></tr>

<tr><td>Text Areas:</td><td><textarea name="textarea" rows="2" cols="20"/></td></tr>

<tr><td>Selection:</td><td><select name="select"><option selected="selected">XML</option><option>SGML</option></select></td></tr>

<tr><td>Multiple Selection:</td><td><select name="mselect" multiple="multiple"><option>242</option><option>290-3</option><option>290-13</option></select>

</table></form>]]></pre>
			</slide>
			<slide id="form-get">
				<title>Forms and GET</title>
				<ul>
					<li>Limited to string-oriented form values</li>
					<ul>
						<li>but HTML forms also allow file upload (this requires <code>POST</code>)</li>
					</ul>
					<li>All values of all form input fields are collected</li>
					<ul>
						<li>for text and selection fields, this is one input field</li>
						<li>for checkboxes and radio buttons, this collects the selected fields</li>
					</ul>
					<li>The browser composes a URI query string</li>
					<ul>
						<li>the form submission is a set of name/value pairs (names may appear more than once!)</li>
						<li>using URI query string notation, it is appended to the URI of the form's <xml>action</xml></li>
					</ul>
					<li><code>GET</code> is good!</li>
					<ul>
						<li>URI-encoded queries can be bookmarked and otherwise reused (e.g., cached)</li>
						<li>if possible, use <code>GET</code> when implementing a form</li>
					</ul>
				</ul>
			</slide>
			<slide id="form-post">
				<title>Forms and POST</title>
				<ul>
					<li><code>GET</code> encodes the values in the URI</li>
					<ul>
						<li>for file uploads, this is not possible</li>
						<li>HTTP's <code>POST</code> request method can upload data</li>
					</ul>
					<li><code>POST</code> sends a request containing an entity</li>
					<ul>
						<li>the HTTP request then looks similar to a response (header fields and entity)</li>
						<li>the receiving process (the Web server) accepts the POST body</li>
					</ul>
					<li>Entities can use any format (it is specified in a header field)</li>
					<ul>
						<li>just like e-mails, entities can have multiple parts</li>
						<li>the parts are separated using the standard MIME mechanism</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>POST Form Processing</title>
				<ul>
					<li><code>POST</code> is used if the <elem>form</elem> specifies it</li>
					<ul>
						<li>it can (but should not) be used for non-file forms</li>
						<li>it should be used for file upload forms (otherwise, only the name is uploaded)</li>
					</ul>
					<li>File upload forms must specify the appropriate encoding</li>
					<ul>
						<li><q><code>application/x-www-form-urlencoded</code></q> is the default (values in the entity)</li>
						<li><q><code>multipart/form-data</code></q> is required for file upload (multipart form data)</li>
					</ul>
					<li>The server side must be prepared to receive <code>POST</code> requests</li>
					<ul>
						<li>it must parse the entity rather than the URI's query string</li>
						<li>form values can then be extracted from the entity</li>
						<li>some environments (e.g., PHP) allow to handle <code>GET</code>/<code>POST</code> transparently</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Processing of Form Data</title>
				<ul>
					<li>Form data is always encoded</li>
					<ul>
						<li>as a query string when using <code>GET</code></li>
						<li>in an encoded entity when using <code>POST</code></li>
						<li>in a multipart entity when using <code>POST</code> with <code>multipart/form-data</code></li>
					</ul>
					<li>Parsing the form data should be done by existing software</li>
					<ul>
						<li>most Web-aware programming environments provide this functionality</li>
						<li>PHP allows access through different mechanisms</li>
					</ul>
				</ul>
				<listing src="form-variables.php"/>
			</slide>
			<slide>
				<title>Structuring Forms</title>
				<ul>
					<li>HTML forms are very loosely structured</li>
					<ul>
						<li><elem>form</elem> somewhere representing the container</li>
						<li>inside the <elem>form</elem> a random collection of HTML and form inputs</li>
					</ul>
					<li>Visually, the structure often is (and should be) easy to see</li>
					<ul>
						<li>for non-visual access, more structure must be provided</li>
						<li>accessibility has become a major issue on the Web</li>
					</ul>
					<li>Accessibility has many different facets</li>
					<ul>
						<li>voice browsers must be able to read aloud Web forms</li>
						<li>gateways should be able to intelligently re-structure Web forms</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Labels</title>
				<ul>
					<li>Label and form control are not connected by HTML</li>
				</ul>
<pre><![CDATA[<tr><td>Text:</td><td><input type="text" name="text"/></td></tr>
<tr><td>Password:</td><td><input type="password" name="password"/></td></tr>]]></pre>
				<ul>
					<li>The <elem>label</elem> element allows to make this connection</li>
					<ul>
						<li>it connects a form control with the describing label</li>
						<li>this association is now accessible to clients for processing</li>
					</ul>
				</ul>
<pre><![CDATA[<tr>
<td><label for="textctrl">Text:</label></td>
<td><input type="text" name="text" id="textctrl"/></td>
</tr>
<tr>
<td><label for="pwdctrl">Password:</label></td>
<td><input type="password" name="password" id="pwdctrl"/></td>
</tr>]]></pre>
			</slide>
			<slide>
				<title>Fieldsets</title>
				<ul>
					<li>Complex forms may need structuring</li>
					<ul>
						<li>groups of controls for subsets of the collected data</li>
						<li>this structure should be represented in markup</li>
					</ul>
				</ul>
				<pre><![CDATA[<fieldset><legend>Billing</legend>billing form controls …</fieldset>
<fieldset><legend>Shipping</legend> shipping form controls … </fieldset>]]></pre>
				<ul>
					<li>Excellent example for HTML's markup design philosophy</li>
					<ul>
						<li>if a client does not support fieldsets, the elements are ignored</li>
						<li>the title of the fieldset will be displayed, because it is text</li>
					</ul>
				</ul>
				<div style="margin : 2%">
					<fieldset><legend>Billing</legend><em>billing form controls …</em></fieldset>
				</div>
				<div style="margin : 2%">
					<fieldset><legend>Shipping</legend><em>shipping form controls …</em></fieldset>
				</div>
			</slide>
			<slide>
				<title>Tabbing in Forms</title>
				<ul>
					<li>Tabbing is a very convenient way of navigating a form</li>
					<ul>
						<li>after completing one field, users should be taken to the next</li>
						<li>the order should be defined by the form creator, not by accident</li>
					</ul>
					<li>the <html>tabindex</html> attribute defines the tabbing order</li>
					<ul>
						<li>it contains a number which is interpreted relative to other numbers</li>
						<li>all form controls may carry a <html>tabindex</html> attribute</li>
					</ul>
					<li><html>tabindex</html> 1-9:
						<select tabindex="1"><option>1</option></select>
						<select tabindex="7"><option>7</option></select>
						<select tabindex="3"><option>3</option></select>
						<select tabindex="6"><option>6</option></select>
						<select tabindex="8"><option>8</option></select>
						<select tabindex="2"><option>2</option></select>
						<select tabindex="1"><option>1</option></select>
						<select tabindex="4"><option>4</option></select>
						<select tabindex="5"><option>5</option></select>
						<select tabindex="9"><option>9</option></select>
					</li>
				</ul>
			</slide>
			<slide>
				<title>Disabled and Readonly Controls</title>
				<ul>
					<li>In complex scenarios, certain controls may be disabled or readonly</li>
					<ul>
						<li>based on a workflow, some controls may not apply in all cases</li>
						<li>for the sake of a consistent view, they should still be included in the interface</li>
					</ul>
					<li>Disabled controls are not used</li>
					<ul>
						<li>they cannot be tabbed to and never receive focus</li>
						<li>their value is not included in the form's submission data</li>
					</ul>
					<li>Readonly controls cannot be changed</li>
					<ul>
						<li>they can be tabbed to and may receive focus</li>
						<li>their <em>value</em> may not be changed (important for radio buttons and checkboxes!)</li>
						<li>their value is included in the form's submission data</li>
					</ul>
					<li>Important: Never trust the Browser!</li>
				</ul>
			</slide>
			<slide>
				<title>Disabled and Readonly Controls Display</title>
					<table style="margin : 2% ; width : 90% ; " rules="groups" cellpadding="5">
						<thead>
							<td/>
							<th>Normal Control</th>
							<th>Disabled Control</th>
							<th>Readonly Control</th>
						</thead>
						<tbody>
							<tr><td valign="top" align="right">Text:</td><td><input type="text" name="text1" value="text input"/></td><td><input disabled="disabled" type="text" name="text2" value="text input"/></td><td><input readonly="readonly" type="text" name="text3" value="text input"/></td></tr>
							<tr><td valign="top" align="right">Password:</td><td><input type="password" name="password1" value="hidden text"/></td><td><input disabled="disabled" type="password" name="password2" value="hidden text"/></td><td><input readonly="readonly" type="password" name="password3" value="hidden text"/></td></tr>
							<tr><td valign="top" align="right">Checkbox:</td><td><input type="checkbox" name="check1" value="1"/> <input type="checkbox" name="check1" checked="checked" value="2"/> <input type="checkbox" name="check1" value="3"/></td><td><input disabled="disabled" type="checkbox" name="check2" value="1"/> <input disabled="disabled" type="checkbox" name="check2" checked="checked" value="2"/> <input disabled="disabled" type="checkbox" name="check2" value="3"/></td><td><input readonly="readonly" type="checkbox" name="check3" value="1"/> <input readonly="readonly" type="checkbox" name="check3" checked="checked" value="2"/> <input readonly="readonly" type="checkbox" name="check3" value="3"/> !</td></tr>
							<tr><td valign="top" align="right">Radio Button:</td><td><input type="radio" name="radio1" value="1"/> <input type="radio" name="radio1" checked="checked" value="2"/> <input type="radio" name="radio1" value="3"/></td><td><input disabled="disabled" type="radio" name="radio2" value="1"/> <input disabled="disabled" type="radio" name="radio2" checked="checked" value="2"/> <input disabled="disabled" type="radio" name="radio2" value="3"/></td><td><input readonly="readonly" type="radio" name="radio3" value="1"/> <input readonly="readonly" type="radio" name="radio3" checked="checked" value="2"/> <input readonly="readonly" type="radio" name="radio3" value="3"/> !</td></tr>
							<tr><td valign="top" align="right">File Upload:</td><td><input name="file1" type="file"/></td><td><input disabled="disabled" name="file2" type="file"/></td><td><input readonly="readonly" name="file3" type="file"/> !</td></tr>
							<tr><td valign="top" align="right">Text Areas:</td><td><textarea name="textarea1" rows="2" cols="20">initial text</textarea></td><td><textarea disabled="disabled" name="textarea2" rows="2" cols="20">initial text</textarea></td><td><textarea readonly="readonly" name="textarea3" rows="2" cols="20">initial text</textarea></td></tr>
							<tr><td valign="top" align="right">Selection:</td><td><select name="select1"><option selected="selected">XML</option><option>SGML</option></select></td><td><select disabled="disabled" name="select2"><option selected="selected">XML</option><option>SGML</option></select></td><td rowspan="2" valign="middle">[ not supported ]</td></tr>
							<tr><td valign="top" align="right">Multiple Selection:</td><td><select name="mselect1" multiple="multiple"><option>242</option><option>290-3</option><option>290-13</option></select></td><td><select disabled="disabled" name="mselect2" multiple="multiple"><option>242</option><option>290-3</option><option>290-13</option></select></td></tr>
						</tbody>
					</table>
			</slide>
		</part>
        <part>
			<title>XHTML</title>
			<slide>
				<title>XHTML and HTML</title>
				<img style="width : 90% ; margin : 2% ; " src="html-sgml-xhtml-xml.png" title="Relationship of HTML, SGML, XHTML, and XML"/>
			</slide>
			<slide>
				<title>Why XHTML?</title>
				<ul>
					<li>XHTML is XML and can be used with XML tools</li>
					<li>HTML is not XML and cannot be used with XML tools</li>
					<li>HTML very often is not validated</li>
					<ul>
						<li><em>tag soup</em> that is hard to work with (text-based processing)</li>
						<li>much harder to process as a machine-readable resource</li>
					</ul>
					<li>Browsers behave differently for HTML and XHTML</li>
					<ul>
						<li>backwards compatibility mode often is triggered by HTML</li>
						<li>XHTML often triggers (more) standards-compliant behavior</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>HTML → XHTML</title>
				<ul>
					<li>Element and attributes names are lowercase</li>	
					<li>End tags are required</li>
					<li>Empty elements should use <em>null end-tag</em> syntax (with a space)</li>
					<li>Attribute values must always be quoted</li>
				</ul>
				<pre><![CDATA[<P>Paragraphs often are not closed properly.
<IMG WIDTH=200 HEIGHT=300 SRC="test.png">
<P>And images by definition are always empty elements.]]></pre>
				<pre><![CDATA[<p>Paragraphs often are not closed properly.</p>
<img width="200" height="300" src="test.png" />
<p>And images by definition are always empty elements.</p>]]></pre>
			</slide>
        </part>
        <part>
			<title>Conclusions</title>
			<slide>
				<title>HTML Matters</title>
				<ul>
					<li>HTML is not just getting text displayed</li>
					<li>Good HTML allows better browsing</li>
					<li>First represent as much as possible in HTML</li>
					<li>Then add what is missing as CSS and/or microformats</li>
					<li>Graceful degradation is important</li>
				</ul>
			</slide>
        </part>
    </presentation>
	<presentation id="css">
		<title short="CSS">Cascading Style Sheets (CSS)</title>
		<date>2007-10-04</date>
		<toc class="reading"><a href="http://www.w3.org/TR/css-beijing" title='W3C&apos;s "Cascading Style Sheets (CSS) Snapshot 2007"'>CSS Snapshot</a>&#160;· <a href="http://www.w3.org/MarkUp/Guide/Style" title='W3C&apos;s "A Touch of Style"'>Touch of Style</a></toc>
		<toc class="resources"><a href="http://www.w3.org/Style/CSS/" title="W3C CSS Specs">Specs</a>&#160;· <a href="http://jigsaw.w3.org/css-validator/" title="W3C CSS Validator">Validator</a></toc>
		<toc class="abstract"><em>Cascading Stylesheets (CSS)</em> have been designed as a language for better separating presentation-specific issues from the structuring of documents as provided by HTML. CSS uses a simple model of <em>selectors</em> and <em>declarations</em>. Selectors specify to which elements of a document a set of declarations (each being a value assigned to a property) apply; in addition there is a model of how property values are inherited and cascaded. The biggest limitation of CSS is that it cannot change the structure of the displayed document.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<part>
			<title>Why CSS?</title>
			<slide>
				<title>Structure vs. Layout</title>
				<ul>
					<li>HTML started as very simple layout-oriented structures</li>
					<ul>
						<li>more layout control was introduced as attributes (<xml>align</xml>, <xml>color</xml>)</li>
						<li>HTML became increasingly <q>polluted</q> by layout information</li>
					</ul>
					<li>CSS was introduced as a format for layout information</li>
					<ul>
						<li>the HTML can be kept simple, containing only the structures</li>
						<li>layout information can be reused by using separate CSS files</li>
					</ul>
					<li>CSS has been designed for HTML</li>
					<ul>
						<li>it has been generalized to also cover XML</li>
						<li>the HTML heritage is still very visible in CSS</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>HTML vs. XML</title>
				<listing src="naked.html" line="2-17"/>
				<listing src="styled.xml" line="3-18"/>
			</slide>
			<slide>
				<title>HTML vs. XML</title>
				<ul>
					<li>HTML's built-in formatting rules can be expressed by CSS</li>
					<ul>
						<li>CSS has been extended to cover all HTML formatting</li>
						<li>any element can be defined to be formatted like an HTML element</li>
					</ul>
				</ul>
				<listing src="naked.css"/>
			</slide>
			<slide>
				<title>What's Missing?</title>
				<ol>
					<li>Restructuring content</li>
					<ul>
						<li>CSS assigns formatting properties to elements</li>
						<li>the document tree which is formatted cannot be restructured</li>
						<li>parts can be ignored or new parts can be inserted</li>
					</ul>
					<li>Interpreting content</li>
					<ul>
						<li><elem>img</elem> has a lot of special meanings attached</li>
						<li>all form elements have very special semantics</li>
					</ul>
				</ol>
			</slide>
		</part>
		<part>
			<title>How CSS Works</title>
			<slide>
				<title>CSS in Action</title>
				<listing src="zengarden.html" line="17-30" href="http://www.csszengarden.com/"/>
			</slide>
			<slide>
				<title>HTML and CSS</title>
				<ul>
					<li>CSS specifies how HTML elements are formatted</li>
					<ol>
						<li>formatting can be attached to every element (redundant inside document)</li>
						<li>formatting can be included in document (redundant across documents)</li>
						<li>separate CSS files describe the formatting (best reuse)</li>
					</ol>
					<li>Any combination of these methods is possible</li>
				</ul>
				<listing src="css-usage.html" line="3-13"/>
			</slide>
			<slide>
				<title>Formatting Model</title>
				<ul>
					<li>Properties are central to the CSS formatting model</li>
					<ol>
						<li>create a document tree</li>
						<li>identify the media type (e.g., <css>screen</css> or <css>print</css>)</li>
						<li>retrieve all stylesheets required for the media type</li>
						<li>assign values to all properties in the document tree</li>
						<li>generate a <em>formatting structure</em> (a different tree)</li>
						<li>render the formatting structure on the target medium</li>
					</ol>
					<li>Properties control the rendering of elements</li>
					<li>Styling in CSS means assigning values to properties</li>
				</ul>
			</slide>
		</part>
		<part id="css-strategies">
			<title>CSS Strategies</title>
			<slide id="css-classes">
				<title>Use Classes &amp; Containers</title>
				<ul>
					<li>CSS code should never show up in your HTML</li>
					<li>Classes should reflect content or formatting</li>
					<li><link href="html-containers">Containers</link> can restrict styles to a context</li>
					<li>Context can be nested</li>
					<ul>
						<li>orthogonal concepts should be represented as nested classes</li>
						<li>for example, pages for <q>staff</q> and <q>faculty</q> and <q>current</q> and <q>past</q> as classification</li>
						<li>different levels of formatting sophistication can be implemented with CSS only</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Avoid Redundant CSS Code</title>
				<ul>
					<li>Whenever appropriate, <css>inherit</css> properties</li>
					<ul>
						<li>for invisible links use <css>a { color : inherit ; }</css></li>
					</ul>
					<li>Use various rules for various levels of style sophistication</li>
				</ul>
			</slide>
		</part>
		<part id="css-properties">
			<title>Properties</title>
			<slide>
				<title>Formatting Instructions</title>
				<ul>
					<li>Properties define how elements are formatted</li>
					<ul>
						<li>they define a specific facet of formatting</li>
						<li>they may have interdependencies with other properties</li>
						<li>they can be assigned explicitly</li>
						<li>they may be defined through <link href="css-cascading"/> or <link href="css-inheritance"/></li>
					</ul>
					<li>A property has a name and is used in a name/value-pair</li>
					<ul>
						<li>the name identifies the property that is being set</li>
						<li>the value space depends on the property</li>
						<li>some properties accept complex values</li>
						<li>sets of values: <css>p { font : bold italic large Palatino }</css></li>
						<li>sequences of values: <css>p { font-family : "Segoe UI", verdana, helvetica, arial, sans-serif }</css></li>
					</ul>
					<li>Property specifications can be grouped</li>
					<ul>
						<li><css>.thinboxed { border-width : 1px ; padding : 10px ; margin : 5px }</css></li>
					</ul>
				</ul>
			</slide>
			<part>
				<title>CSS1 Properties</title>
				<slide>
					<title>Factoring out HTML</title>
					<ul>
						<li>CSS1 was published in <a href="http://www.w3.org/TR/REC-CSS1-961217">1996</a> and revised in <a href="http://www.w3.org/TR/1999/REC-CSS1-19990111">1999</a></li>
						<li>HTML suffered from too many attributes</li>
						<ul>
							<li>layout information was specified as CSS</li>
							<li>style attributes in HTML were marked as <q>deprecated</q></li>
						</ul>
						<li>A small set of formatting features as CSS properties</li>
						<ul>
							<li>font: <css>p { font : 80% sans-serif }</css></li>
							<li>color and background: <css>body { background : url(logo.jpeg) right top }</css></li>
							<li>text: <css>h1 { text-transform : uppercase }</css></li>
							<li>box: <css>p.quote { border-style : solid dotted }</css></li>
							<li>classification: <css>img { display : none }</css></li>
						</ul>
					</ul>
				</slide>
			</part>
			<part>
				<title>CSS2 Properties</title>
				<slide>
					<title>CSS2</title>
					<ul>
						<li>CSS2 was published in <a href="http://www.w3.org/TR/1998/REC-CSS2-19980512/">1998</a> and is <a href="http://www.w3.org/TR/CSS21/">still being  revised (CSS2¹)</a></li>
						<li>CSS2¹ is what you can expect from modern browsers</li>
						<ul>
							<li>with IE (even IE7) being the exception</li>
						</ul>
						<li>CSS2 is a single and coherent specification</li>
						<ul>
							<li>CSS3 is a jungle of concurrent module development</li>
							<li>CSS3 will never be finished (some modules will, though)</li>
						</ul>
					</ul>
				</slide>
				<slide id="generated-content">
					<title>Generated Content</title>
					<ul>
						<li>CSS1 had no way of adding information to the document</li>
						<ul>
							<li>by using <css>display</css>, parts of the document could be ignored</li>
						</ul>
						<li><em>Generated content</em> allows content to come from the CSS</li>
						<ul>
							<li>only possible with <css>:before</css> and <css>:after</css> <em>pseudo-elements</em></li>
							<li>static strings: <css>p.abstract:before { content : "Abstract: " }</css></li>
							<li>special effects like <q>quotes</q>: <css>q:before { content : open-quote } </css></li>
							<li>counters: <css>h1:before { content: "Chapter " counter(chapter) ". " ; counter-increment : chapter }</css></li>
						</ul>
						<li>Quotes can be defined as being language dependent</li>
						<ul>
							<li><css>q:lang(en) { quotes : '"' '"' "'" "'" }</css></li>
							<li><css>q:lang(no) { quotes : "«" "»" '"' '"' }</css></li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Tables</title>
					<ul>
						<li>CSS1 does not address table formatting</li>
						<ul>
							<li>table layout still had to be done using HTML attributes</li>
							<li>a lot of redundant code specifying cell alignment and borders</li>
						</ul>
						<li>CSS2 introduces tables on the CSS level</li>
					</ul>
					<pre>table    { display: table }
tr       { display: table-row }
thead    { display: table-header-group }
tbody    { display: table-row-group }
tfoot    { display: table-footer-group }
col      { display: table-column }
colgroup { display: table-column-group }
td, th   { display: table-cell }
caption  { display: table-caption }</pre>
				</slide>
				<slide>
					<title>Fixed vs. Automatic Table Layout</title>
					<ul>
						<li>HTML defines a complex table rendering algorithm</li>
						<ul>
							<li>tables are rendered incrementally</li>
							<li>table layout is determined by looking at the complete table</li>
						</ul>
					</ul>
					<table width="90%" cellspacing="10%">
						<thead>
							<tr>
								<th>Automatic</th>
								<th>Fixed</th>
							</tr>
						</thead>
						<tr>
							<td width="45%">
								<table border="1">
									<tr>
										<td>col 1 row 1</td>
										<td>col 2 row 1 col 2 row 1</td>
										<td>col 3 row 1 col 3 row 1 col 3 row 1</td>
									</tr>
									<tr>
										<td>col 1 row 2</td>
										<td>col 2 row 2 col 2 row 2</td>
										<td>col 3 row 2 col 3 row 2 col 3 row 2</td>
									</tr>
								</table>
							</td>
							<td width="45%">
								<table border="1" style="table-layout : fixed ; ">
									<tr>
										<td width="33%">col 1 row 1</td>
										<td width="33%">col 2 row 1 col 2 row 1</td>
										<td width="33%">col 3 row 1 col 3 row 1 col 3 row 1</td>
									</tr>
									<tr>
										<td>col 1 row 2</td>
										<td>col 2 row 2 col 2 row 2</td>
										<td>col 3 row 2 col 3 row 2 col 3 row 2</td>
									</tr>
								</table>
							</td>
						</tr>
					</table>
					<ul>
						<li>Clipping of contents allows more freedom</li>
						<ul>
							<li>HTML tables are designed to show everything</li>
							<li>many applications work better <a href="http://dret.net/glossary/xml">when table contents are clipped</a></li>
						</ul>
					</ul>
				</slide>
			</part>
			<part>
				<title>CSS3 Properties</title>
				<slide>
					<title>CSS3</title>
					<ul>
						<li>CSS3 is modularized and huge</li>
						<li>Developments for different applications and scenarios</li>
						<ul>
							<li><a href="http://www.w3.org/Style/CSS/current-work">under construction</a> for some time to come</li>
							<li>implementations have to wait until the modules are more stable</li>
						</ul>
						<li>CSS3 contains many powerful features</li>
						<ul>
							<li>more powerful features mean a higher fall when <em>fallback behavior</em> occurs</li>
							<li>CSS3 modules will probably undergo evolutionary selection and mutation</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Multi-Column Layout</title>
					<ul>
						<li>Most column-based layouts use tables</li>
						<ul>
							<li>table columns are filled left-to-right, then top-to-bottom</li>
							<li>multicolumns allow content to flow between columns</li>
						</ul>
						<li>Multicolumn layouts are used in many Web pages</li>
						<li>Publishing tools are good at hiding the <elem>table</elem> problems</li>
					</ul>
					<listing src="multicol.html" line="2-14"/>
				</slide>
			</part>
		</part>
		<part id="css-selectors">
			<title>Selectors</title>
			<slide>
				<title>Select and Style</title>
				<ul>
					<li><link href="css-properties"/> are applied to elements</li>
					<ul>
						<li>properties can be directly applied in an element's <attr>style</attr> attribute</li>
						<li>in all other cases, <em>selectors</em> are used to select the styled elements</li>
					</ul>
					<li>Selectors are good for reusable CSS code</li>
					<ul>
						<li>identifying the most appropriate formatting classes is not easy</li>
						<li>planning for CSS for a larger site is a difficult task</li>
					</ul>
					<li>CSS project management should separate selectors and properties</li>
					<ol>
						<li>selectors are about which things should be identified and styled</li>
						<li>properties are about how this styling is implemented</li>
					</ol>
				</ul>
			</slide>
			<part id="css1-selectors">
				<title>CSS1 Selectors</title>
				<slide>
					<title>CSS for Dummies</title>
					<ul>
						<li>Very small set of selectors</li>
						<ul>
							<li>selecting elements by name: <css>h1 { font-size : large }</css></li>
							<li>selecting elements by their <xml>id</xml>: <css>#author { font-weight : bold }</css></li>
							<li>selecting elements by their <xml>class</xml>: <css>.abstract { font-size : small }</css></li>
							<li>combining these mechanisms: <css>p.warning { color : red } </css></li>
						</ul>
						<li>Pseudo-classes and -elements allow interesting effects</li>
						<ul>
							<li><elem>a</elem> links have state: <css>a:visited</css> and <css>a:active</css></li>
							<li>selection without markup: <css>p:first-letter</css> and <css>p:first-line</css></li>
						</ul>
					</ul>
				</slide>
			</part>
			<part>
				<title>CSS2 Selectors</title>
				<slide>
					<title>More Selectors</title>
					<ul>
						<li><link href="css1-selectors"/> are available</li>
						<ul>
							<li>element name, <attr>id</attr>, <attr>class</attr>, and combinations of these</li>
						</ul>
						<li>CSS2 introduced many new selectors</li>
						<ul>
							<li>descendants: <css>ul li { font : italic }</css></li>
							<li>children: <css>ul > li { font : italic }</css></li>
							<li>adjacent siblings: <css>h1 + h2 { margin-top : 0.5em }</css></li>
							<li>attribute matching: <css>h1[lang=nl] { color : orange }</css></li>
						</ul>
						<li>CSS2 selectors are sufficient for most tasks</li>
						<li>Setting <attr>class</attr> attributes is very important</li>
					</ul>
				</slide>
				<slide>
					<title>CSS2 Pseudo Classes</title>
					<ul>
						<li><link href="css1-selectors">CSS1's pseudo-elements</link> are available</li>
						<ul>
							<li>link states and first letter and line of content</li>
						</ul>
						<li>CSS2 adds more qualifications for elements</li>
						<ul>
							<li>first child: <css>p:first-child { text-indent : 0 }</css></li>
							<li>dynamic behavior: <css>a:hover { … } a:active { … } a:focus { … }</css></li>
							<li>language: <css>:lang(de) { quotes: '»' '«' '‹' '›' }</css></li>
							<li><link href="generated-content"/>: <css>q:before { content : open-quote } q:after { content : close-quote }</css></li>
						</ul>
						<li>Support for <link href="i18n+l10n"/></li>
					</ul>
				</slide>
			</part>
			<part>
				<title>CSS3 Selectors</title>
				<slide>
					<title>CSS goes XPath</title>
					<ul>
						<li>CSS3 selectors introduce a wide array of new features</li>
						<ul>
							<li><a href="../xml-fall07/xpath">XPath</a> is a very general selection mechanism</li>
							<li>CSS3 re-invents some XPath features using new names</li>
							<li>other selectors are based on dynamic information, which is more useful</li>
						</ul>
						<li>Some ideas are very useful</li>
						<ul>
							<li><a href="http://dret.net/netdret/publications#wil98">highlighting targets</a>: <css>*:target { outline : red thin solid }</css></li>
							<li>selection highlighting: <css>*:selection { … }</css></li>
							<li>(form) element states: <css>input:disabled { … }</css></li>
						</ul>
						<li>Adoption and demand for other selectors is unclear</li>
						<ul>
							<li>attribute substrings: <css>p[title*="hello"] { … }</css></li>
							<li>counting children: <css>p:nth-child(42) { … }</css></li>
						</ul>
					</ul>
				</slide>
			</part>
		</part>
		<part>
			<title>CSS Mechanics</title>
			<slide id="css-cascading">
				<title>Cascading</title>
				<ul>
					<li>Stylesheets may have three different origins</li>
					<ol>
						<li><em>page authors</em> associate CSS with their pages</li>
						<li><em>users</em> configure their browser to use some CSS</li>
						<li><em>user agents (browsers)</em> have built-in CSS how to style content</li>
					</ol>
					<li>Conflicts must be resolved using the following algorithm</li>
					<ol>
						<li>find all matching declarations (matching media type and selector)</li>
						<li>sort according to importance (browser &lt; user &lt; author)</li>
						<li>same importance must be sorted by specificity (more specific selectors)</li>
						<li>finally, sort by order in which they were specified</li>
					</ol>
					<li><css>!important</css> rules can influence the algorithm</li>
					<ul>
						<li>they are interpreted in step 2 (sorting by importance)</li>
						<li>browser &lt; user &lt; author &lt; author(important) &lt; user(important)</li>
					</ul>
				</ul>
			</slide>
			<slide id="css-inheritance">
				<title>Inheritance</title>
				<ul>
					<li>Properties often are inherited by children</li>
					<ul>
						<li>setting a table's <css>color</css> sets the <css>color</css> for all contents</li>
						<li>without inheritance, CSS stylesheets would have to be very large</li>
					</ul>
					<li>Inheritance is mostly intuitive</li>
					<ul>
						<li>in reality, it is a bit more complicated</li>
					</ul>
					<ol>
						<li><em>specified value:</em> what the property specified (<link href="css-cascading"/>, inheritance, or initial)</li>
						<li><em>computed value:</em> computed based on the environment (e.g., <css>ex</css> → <css>px</css>)</li>
						<li><em>used value:</em> converted to an absolute value (e.g., percentage widths)</li>
						<li><em>actual value:</em> specific for the environment (e.g., borders with pixel fractions)</li>
					</ol>
				</ul>
			</slide>
			<slide id="css-import">
				<title>Structuring Stylesheets</title>
				<ul>
					<li>Stylesheets may need to be structured</li>
					<ul>
						<li>importing CSS code is supported: <css>@import "/dretnet.css" ;</css></li>
						<li>modules of CSS code can be reused in different contexts</li>
					</ul>
					<li>Stylesheets may be specific for a media type</li>
					<ul>
						<li><em>braille, embossed, handheld, print, projection, screen, speech, tty, tv</em></li>
						<li>specified in HTML: <elem>link rel="stylesheet" type="text/css" media="print" href="/print.css"</elem></li>
						<li>specified in CSS: <css>@media print { … }</css></li>
						<li>media-dependent import: <css>@import "/print.css" print ;</css></li>
					</ul>
				</ul>
			</slide>
		</part>
		<part>
			<title>Conclusions</title>
			<slide>
				<title>CSS for Document Styling</title>
				<ul>
					<li>Appropriate for HTML</li>
					<ul>
						<li>Flexible selection of elements using <link href="css-selectors"/></li>
						<li>Powerful formatting of elements using <link href="css-properties"/></li>
						<li>Interesting interface design with <em>pseudo-classes</em> and <em>-elements</em></li>
					</ul>
					<li>Inappropriate for XML</li>
					<ul>
						<li>Assigning values to properties is too simple</li>
						<li>XML documents often need to be restructured</li>
						<li><a href="../xml-fall07/xslt-1">XSLT</a> is the language for restructuring XML</li>
						<li>XML → HTML+CSS is a popular Web publishing setup</li>
					</ul>
				</ul>
			</slide>
		</part>
	</presentation>
    <presentation id="usability" external="usability.pdf">
        <title>Usability</title>
        <date>2007-10-09</date>
        <toc class="reading"><a href="http://portal.acm.org/citation.cfm?id=286067" title='Chapter 3 (pp. 41-64) of Hugh Beyer and Karen Holtzblatt, "Contextual Design: Defining Customer-Centered Systems", Morgan Kaufmann, San Francisco, 1998'>Contextual Design (Chapter 3, pp. 41-64)</a></toc>
        <toc class="resources"><a href="http://www.useit.com/jakob/inspectbook.html">Heuristic Evaluation</a>&#160;· <a href="http://useit.com/" title="Jakob Nielsen's Website">useit.com</a></toc>
        <toc class="abstract">According to the <em>International Organization for Standardization (ISO)</em>, <em>usability</em> defines the extent to which a product can be used by
specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use. We will discuss tradeoffs in the design of Web interfaces to support users goals, and present resources to aid design decisions.</toc>
    </presentation>
    <presentation id="accessibility" external="accessibility.pdf">
        <title>Accessibility</title>
        <date>2007-10-11</date>
        <toc class="reading"><a href="http://doi.acm.org/10.1145/637848.637858" title='Aaron Marcus, "Universal, Ubiquitous, User-Interface Design for the Disabled and Elderly", In: interactions, 10(3):23-27, 2003'>User Interface Design</a></toc>
        <toc class="resources"><a href="http://www.w3.org/WAI/" title='Ben Shneiderman, "Universal Usability", In: Communications of the ACM, 43(5):84-91, May 2005'>Universal Usability</a>&#160;· <a href="http://www.w3.org/WAI/" title="W3C Web Accessibility Initiative">WAI</a>&#160;· <a href="http://www.w3.org/TR/WAI-WEBCONTENT/" title="W3C Web Content Accessibility Guidelines">WCAG</a></toc>
        <toc class="abstract">Web <em>accessibility</em> refers to the degree to which the Web can be used and accessed by people with disabilities. The <em>World Wide Web Consortium (W3C)</em> determines that accessibility specifically involves how people with disabilities can perceive, understand, navigate, interact with, as well contribute to the Web. Techniques for supporting these needs will be discussed and reviewed through examples and exercises.</toc>
    </presentation>
    <presentation id="dhtml">
        <title short="DHTML">Dynamic HTML (DHTML)</title>
        <date>2007-10-16</date>
        <toc class="resources"><a href="http://www.w3.org/DOM/" title="W3C DOM Activity">DOM</a></toc>
        <toc class="abstract"><em>Dynamic HTML (DHTML)</em> refers to the combination of HTML, CSS, the <em>Document Object Model (DOM)</em>, and JavaScript. The <em>Document Object Model (DOM)</em> is an API for markup-structured documents, it is used for HTML as well as for XML. The DOM allows program code to access documents for read and write access. DOM-based access to documents in conjunction with user-originated events (keyboard and mouse events) allows scripting code on Web pages to dynamically update documents.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<slide>
			<title>Scripting on the Web</title>
			<ul>
				<li>Web pages were static HTML</li>
				<ul>
					<li><link href="forms"/> were the only interactive part of Web pages</li>
					<li>interaction is only possible by clicking links and visiting new pages</li>
				</ul>
				<li>Netscape invented the <link href="dom"/> and <em>LiveScript</em></li>
				<ul>
					<li>Java was new and hip, so the language was renamed to <link href="javascript"/></li>
					<li>pages with scripting were more pleasant to use</li>
					<li>other browsers invented their own <q>versions</q> of DOM/JavaScript</li>
				</ul>
				<li>Scripting was and is often used to implement <q>missing functionality</q></li>
				<ul>
					<li>good scripting supports graceful degradation (leaving the page functional)</li>
					<li>bad scripting compromises accessibility when the scripting code does not work</li>
				</ul>
			</ul>
		</slide>
        <part id="dom">
			<title>Document Object Model (DOM)</title>
			<slide>
				<title>Handling Markup</title>
				<ul>
					<li>HTML (and XML) are based on a tree model</li>
					<ul>
						<li>there is one <em>document element</em>: <htmel>html</htmel></li>
						<li>elements may contain elements: <htmel>head</htmel> or <htmel>body</htmel></li>
						<li>element structures can be nested as deep as required</li>
						<li>elements may contain text</li>
						<li>elements may contain text mixed with elements</li>
						<li>elements may have attributes</li>
					</ul>
					<li>Most Web pages are not syntactically correct</li>
					<ul>
						<li>basic markup errors: <code>&lt;b>&lt;i>no tree&lt;b>&lt;i></code></li>
						<li>well-formed markup but not valid HTML</li>
					</ul>
					<li>Browsers do their best to interpret everything as HTML</li>
					<ul>
						<li>fixing errors always is based on assumptions and thus risky</li>
					</ul>
				</ul>
			</slide>
			<slide id="mixed-content">
				<title>Mixed Content</title>
				<p>The term <em>Mixed content</em> in XML refers to elements <a href="http://www.w3.org/TR/xml/#sec-mixed-content">which have text content mixed with elements</a>. What these elements do depends on the elements <img style="height : 1em" src="smiley.gif"/>, but the important point is that they are on the same level as the text nodes of the mixed content.</p>
				<pre><![CDATA[<p>The term <em>Mixed content</em> in XML refers to elements <a href="http://www.w3.org/TR/xml/#sec-mixed-content">which have text content mixed with elements</a>. What these elements do depends on the elements <img style="height : 1em" src="smiley.gif"/>, but the important point is that they are on the same level as the text nodes of the mixed content.</p>]]></pre>
				<img style="width : 90% ; margin : 4% ;" src="mixed-content.png" title="XML tree for mixed content"/>
			</slide>
			<slide>
				<title>Markup to Trees</title>
				<ul>
					<li>Browsers build a DOM tree from the (fixed) markup</li>
					<ul>
						<li>scripting code never works on the markup text, it works on the tree</li>
					</ul>
					<li>DOM trees are an abstraction of the markup</li>
					<ul>
						<li>trees provide convenient navigation facilities</li>
						<li>abstractions provide an insulation against irrelevant markup details</li>
					</ul>
					<li>DOM is available in a large number of programming languages</li>
					<ul>
						<li><link href="javascript"/> is the language supported in Web browsers</li>
						<li>DOM is also available for Java, C, C++, Python, Perl, C#, Ruby, …</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>DOM History</title>
				<ul>
					<li>DOM0 was invented by Netscape (backing the LiveScript/JavaScript)</li>
					<li>DOM1 was the first DOM version produced by the W3C</li>
					<li>DOM2 is the currently available stable version of DOM</li>
					<ul>
						<li>major changes to be compliant with XML and the XML Infoset</li>
					</ul>
					<li>DOM3 is highly modularized and still under development</li>
					<ul>
						<li>more XML technologies such as the ability to use XPath</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>HTML Parser</title>
				<img style="width : 90% ; margin : 2% ; " src="html-parser.png" title="HTML Parser"/>
			</slide>
			<slide>
				<title>DOM2 Map</title>
				<img style="height : 70% ; margin : 2% ; " src="dom2-map.png"/>
			</slide>
			<slide>
				<title>DOM3 Map</title>
				<img style="height : 70% ; margin : 2% ; " src="dom3-map.png"/>
			</slide>
        </part>
        <part id="javascript">
			<title>JavaScript</title>
			<slide>
				<title>Language Names</title>
				<ul>
					<li>Netscape started the language as <em>LiveScript</em></li>
					<li>Netscape renamed the language to <em>JavaScript</em></li>
					<li>Microsoft implemented the language as <em>JScript</em></li>
					<li><a href="http://www.ecma-international.org/" title="European Computer Manufacturers Association">ECMA</a> standardized the language as <em>ECMAScript</em></li>
					<li>Macromedia/Adobe extended the language as <em>ActionScript</em></li>
					<li><a href="http://en.wikipedia.org/wiki/List_of_ECMAScript_engines">Implementations for other platforms</a> are also available</li>
				</ul>
			</slide>
			<slide>
				<title>Scripted Effects</title>
				<listing src="colorfades.html"/>
			</slide>
			<slide>
				<title>Web Programming</title>
				<ul>
					<li>Web programming always requires document access</li>
					<ul>
						<li>user interactions are always going through the document (the interface)</li>
						<li>user interactions create events</li>
						<li>scripting code handles events and updates the document</li>
					</ul>
					<li>Events occur in various contexts</li>
					<ul>
						<li>Netscape decided that events <em>bubble up the tree</em></li>
						<li>Microsoft decided that events are <em>captured top-down</em></li>
						<li>the W3C DOM now has a combined <em>capturing/bubbling</em> model</li>
						<li>event listeners have to decide when they want to be called</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>DOM Event Flow</title>
				<img style="height : 70% ; margin : 2% ; " src="dom-event-flow.png" href="http://www.w3.org/TR/xml-events/#s_intro"/>
			</slide>
			<slide>
				<title>Registering Event Listeners</title>
				<listing src="dom-event-flow.html"/>
			</slide>
        </part>
        <part>
			<title>Conclusions</title>
			<slide>
				<title>Making Web Pages Act &amp; React</title>
				<ul>
					<li>HTML is purely static (form elements allow data input)</li>
					<li>DHTML allows scripting code for dynamic Web pages</li>
					<li>DOM is the abstract data model for scripting code</li>
					<li>JavaScript interacts with users through DOM events</li>
					<li>Scripting should be used with accessibility in mind</li>
				</ul>
			</slide>
        </part>
    </presentation>
    <presentation id="ajax">
        <title short="Ajax">Asynchronous JavaScript and XML (Ajax)</title>
        <date>2007-10-18</date>
        <toc class="resources"><a href="http://www.w3.org/TR/XMLHttpRequest/" title="W3C XMLHttpRequest Spec">XMLHttpRequest</a></toc>
        <toc class="abstract"><em>Asynchronous JavaScript and XML (Ajax)</em> takes DHTML to the next level by allowing server access from within scripting code. This is accomplished by using a standardized API for client/server communications, the <code>XMLHttpRequest</code> object. This objects allows using HTTP connections from within scripting code, and thereby allows scripting code to dynamically reload data from a server in response to user interactions.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
        <part id="ajax-basis">
			<title>Ajax Basics</title>
			<slide>
				<title>Ajax = DHTML + HTTP</title>
				<ul>
					<li><link href="dhtml"/> uses JavaScript <q>locally</q></li>
					<ul>
						<li>the scripting code reacts to user events and accesses the DOM structure</li>
						<li>changes are either hardcoded or derived from user events</li>
					</ul>
					<li>Ajax adds an <link href="http-request">HTTP request</link> method to JavaScript</li>
					<ul>
						<li>scripting code can now request additional data from an HTTP server</li>
						<li>changes can thus be made based on any data received from the server</li>
					</ul>
					<li>Ajax dramatically reduces the number of page reloads</li>
					<ul>
						<li>any change of the page can be done without a complete reload</li>
						<li>based on user interactions, parts of the page can be reloaded</li>
					</ul>
					<li>Ajax has the same interoperability problems as DHTML</li>
				</ul>
			</slide>
			<slide>
				<title>Ajax and DHTML</title>
				<img style="width : 90% ; margin : 2% ; " src="ajax.png" title="Comparison of Ajax and DHTML"/>				
			</slide>
        </part>
		<part id="json">
			<title short="JSON">JavaScript Object Notation (JSON)</title>
			<slide>
				<title>JavaScript and XML</title>
				<ul>
					<li>The <code>XMLHttpRequest</code> API has been built for requesting XML via HTTP</li>
					<ul>
						<li>this is useful because XML is the most popular data format</li>
						<li>all requested data has to be processed by using XML access methods in JavaScript</li>
					</ul>
					<li>JavaScript does not have XML as its internal data model</li>
					<ul>
						<li>the XML received via <code>XMLHttpRequest</code> has to be parsed into a DOM tree</li>
						<li>DOM access in JavaScript is inconvenient for complex operations</li>
						<li>alternatively, the XML can be mapped to JavaScript objects (also requires parsing)</li>
					</ul>
					<li><em>JavaScript Object Notation (JSON)</em> encodes data as JavaScript objects</li>
					<ul>
						<li>because the consumer is written in JavaScript, this is more efficient for the consumer</li>
						<li>this turn the generally usable XML service into a JavaScript-oriented service</li>
						<li>for large-scale applications, it might make sense to provide XML and JSON</li>
						<li>using <link href="http-content-negotiation"/>, this can be negotiated on the HTTP protocol level</li>
					</ul>
				</ul>
			</slide>
			<slide id="json">
				<title>JSON Example</title>
				<listing src="menu.xml"/>
				<listing src="menu.json"/>
			</slide>
			<slide id="json">
				<title>JSON via Content Negotiation</title>
				<ul>
					<li>XML or JSON are just different representations</li>
					<ul>
						<li>they represent the same underlying resource (as identified by the URI)</li>
					</ul>
					<li><link href="http-content-negotiation"/> allows to specify preferences</li>
					<ul>
						<li>clients specify preferences and server respond with the best match</li>
					</ul>
					<li> HTTP <http>Accept</http> specifies the accepted <link href="mime">media types</link></li>
					<ul>
						<li>resources may be available in HTML, XML, or JSON</li>
						<li>depending on the HTTP request, the server responds with the best representation</li>
						<li>reduces processing time on the client and can be cached</li>
					</ul>
					<li>Really smart Ajax frameworks could even hide the content negotiation</li>
					<ul>
						<li>request JSON or XML with XML being the lower priority</li>
						<li>if XML is sent by the server, it has to be parsed into a JavaScript object</li>
						<li>the end result is always a JavaScript object for the framework user</li>
					</ul>
				</ul>
			</slide>
		</part>
        <part>
			<title>Conclusions</title>
			<slide>
				<title>Client/Server Recreated</title>
				<ul>
					<li>Ajax implements a lightweight client/server model</li>
					<li>Ajax can range from helper functions to complete local applications</li>
					<li>Ajax can help in RESTful architectures (less server state)</li>
					<li>Ajax seriously challenges the basic navigation model of the Web</li>
					<li>Creating better interfaces for Ajax applications is a research issue</li>
				</ul>
			</slide>
        </part>
    </presentation>
    <presentation id="i18n+l10n">
        <title short="I18N &amp; L10N">Internationalization (I18N) &amp; Localization (L10N)</title>
        <date>2007-10-23</date>
        <toc class="reading"><a href="http://www.w3.org/TR/itsreq/" title='W3C&apos;s "Internationalization and Localization Markup Requirements"'>I18N &amp; L10N Markup</a></toc>
        <toc class="resources"><a href="http://www.w3.org/TR/i18n-html-tech-lang/" title='W3C&apos;s "Specifying Language in XHTML &amp; HTML Content"'>Content</a>&#160;· <a href="http://www.w3.org/TR/its/" title='W3C&apos;s "Internationalization Tag Set (ITS) Version 1.0"'>Tag Set</a></toc>
        <toc class="abstract">Many publishing environments need to support multiple languages. In many cases, the requirement to support multiple languages surfaces in later stages of a product development or publishing solution, which can cause major design changes, driving up costs. <em>Internationalization (I18N)</em> is the approach to design systems which can adapt to different locales. <em>Localization (L10N)</em> is the activity to identify, define, and encode locales, based on internationalized software.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<slide>
			<title>I18N &amp; L10N</title>
			<listing src="blinkbase.xml" line="39-41"/>
			<listing src="blinkbase-i18n.xml" line="66-77"/>
		</slide>
		<slide>
			<title>What is Language?</title>
			<ul>
				<li>Language is more than the encoding of individual words</li>
				<ul>
					<li>languages and culture are deeply intertwined and inseparable</li>
					<li>ideally, systems/solutions should adapt to culture, not only to language</li>
					<li>on a superficial level, adapting to language is useful a first step</li>
				</ul>
				<li>Languages have properties which are beyond character sequences</li>
				<ul>
					<li>for right-to-left languages, screen layout should be done right-to-left</li>
					<li>if languages are mixed, one language has to be the preferred language</li>
				</ul>
				<li>Language identification and selection are basic I18N tasks</li>
				<ul>
					<li>the <q>one language fits all</q> assumption is becoming increasingly inappropriate</li>
					<li>the <q>just switch the labels</q> strategy also may be too little for true L10N</li>
				</ul>
			</ul>
		</slide>
		<slide id="beyond-language">
			<title>Beyond Language</title>
			<img src="uighur.png" style="float : right ; margin : 1em ; " href="http://www.linguamongolia.co.uk/script1.html" title='"Mongol" in Uighur Script'/>
			<ul>
				<li>Directionality is the concept how written language is organized</li>
				<ul>
					<li>early languages had no inherent directionality (even zigzag writing was possible)</li>
					<li>the majority of today's languages are <em>left-to-right</em> languages</li>
					<li>Arabic and Hebrew are two popular <em>right-to-left</em> languages</li>
					<li>Chinese can be written <em>top-to-bottom</em> and <em>right-to-left</em></li>
					<li>Mongolian (using the <a href="http://www.linguamongolia.co.uk/">Uighur alphabet</a>) is written <em>top-to-bottom</em> and <em>left-to-right</em></li>
				</ul>
				<li>Icons can be very culture-specific and often need to be localized as well</li>
				<img src="owl.png" style="float : left ; width : 20% ; " title="Wisdom or Witchcraft?"/>
				<ul>
					<li>icons are pictorial metaphors (rooted in language and/or culture)</li>
					<li>language-specific metaphors may not work across languages (e.g., <em>OK gesture</em>)</li>
					<li>culture-specific metaphors may not work across cultures (e.g., <em>owls</em>)</li>
				</ul>
			</ul>
		</slide>
		<slide>
			<title>Directionality and Screen Layout</title>
			<img style="width : 90% ; margin : 2% ; " src="outlook-right-to-left.png" title="Right-to-Left Layout for Outlook Web Access"/>				
		</slide>
        <part id="i18n">
			<title short="I18N">Internationalization (I18N)</title>
			<slide>
				<title>Definition</title>
				<blockquote>Internationalization is the design and development of a product, application or document content that enables easy localization for target audiences that vary in culture, region, or language.</blockquote>
				<ul>
					<li>I18N starts at the design phase and influences the complete process</li>
					<li>The upfront costs of I18N are considerable (increased complexity)</li>
					<li>The costs of retroactive I18N are much higher than that</li>
				</ul>
			</slide>
			<slide>
				<title>I18N Tasks</title>
				<ol>
					<li>UI elements (windows, menus) must be modified to accept translated text</li>
					<li>Static text must be made configurable</li>
					<li>Icons and graphics must be changed to be more culturally appropriate</li>
					<li>Sound files that contain spoken language must be re-recorded</li>
					<li>Online help must be translated</li>
					<li>Dynamic text (dates, times) must be formatted using the locale</li>
					<li>Text handling code must calculate word breaks using the locale</li>
					<li>Tabular data must be sortable using the locale</li>
				</ol>
			</slide>
		</part>
        <part id="l10n">
			<title short="L10N">Localization (L10N)</title>
			<slide>
				<title>Definition</title>
				<blockquote>Localization refers to the adaptation of a product, application or document content to meet the language, cultural and other requirements of a specific target market (a <q>locale</q>).</blockquote>
				<ul>
					<li>Without proper I18N, L10N is a very expensive and risky process</li>
					<li>L10N based on internationalized products should be straight-forward</li>
					<li>during L10N for specific locales, new areas for I18N might be identified</li>
					<ul>
						<li>some non-internationalized part of the product is identified as inappropriate</li>
					</ul>
					<li>L10N should be regarded as an input for improved I18N</li>
				</ul>
			</slide>
			<slide>
				<title>L10N Tasks</title>
				<ol>
					<li>Create translations for all interface elements</li>
					<li>Translate all static texts</li>
					<li>If necessary, create localized icons and graphics</li>
					<li>Any spoken text must be recorded in the target language</li>
					<li>Make sure that the localized product uses the localized online help</li>
					<li>Formatting of data types must be treated locale-specific</li>
					<li>If necessary, dictionaries and other language tools must be integrated</li>
					<li>Sorting functions in the code must respect the locale</li>
				</ol>
			</slide>
        </part>
		<part id="xml:lang">
			<title>Language Identification in Resources</title>
			<slide>
				<title>Language Codes</title>
				<ul>
					<li>Language identification is required in many contexts</li>
					<ul>
						<li>successful identification needs a standardized set of <em>language tags</em></li>
					</ul>
					<li><a href="http://dret.net/rfc-index/reference/RFC4646" title="Language Tag RFC">RFC 4646</a> defines <q>Tags for Identifying Languages</q></li>
					<ul>
						<li>two letter codes such as <code>en</code> are interpreted according to <a href="http://dret.net/biblio/reference/iso639-1">ISO 639-1</a></li>
						<li>three letter codes such as <code>eng</code> are interpreted according to <a href="http://dret.net/biblio/reference/iso639-2">ISO 639-2</a></li>
						<li><q><code>x-</code></q> indicates a value which is not standardized (requires mutual agreement)</li>
						<li><em>subtags</em> such as <code>en-US</code> specify additional properties (regions, dialects, scripts, …)</li>
					</ul>
					<li><a href="http://dret.net/rfc-index/reference/RFC4647" title="Language Tag Matching RFC">RFC 4647</a> defines the <q>Matching of Language Tags</q></li>
					<ul>
						<li>matchmaking between requested and available languages</li>
						<li>how to proceed if <code>en-US</code> or <code>de</code> are requested but available variants are <code>en</code> and <code>de</code></li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>ISO 639-2 Code List</title>
				<listing src="ISO-639-2_values_8bits.txt" href="http://www.loc.gov/standards/iso639-2/ISO-639-2_values_8bits.txt" line="115-136" title="ISO 639-2 Code List"/>
			</slide>
			<slide>
				<title>IANA Language Subtag Registry</title>
				<listing src="language-subtag-registry.txt" href="http://www.iana.org/assignments/language-subtag-registry" line="4411-4431" title="IANA Language Subtag Registry"/>
			</slide>
			<slide>
				<title>Language Identification in XML</title>
				<ul>
					<li>XML itself has (almost) no semantics</li>
					<ul>
						<li>applications create or use schemas and the semantics are associated with the schema</li>
						<li>XML is the serialization of the semantics which are embodied in the schema</li>
					</ul>
					<li>XML has a very small set of built-in semantics</li>
					<ul>
						<li><a href="http://www.w3.org/TR/xml/#sec-lang-tag" title="W3C XML Spec: Language Identification"><code>xml:lang</code></a> is a reserved attribute for encoding the language of content</li>
						<li><a href="http://www.w3.org/TR/xml-id/" title="W3C xml:id Spec"><code>xml:id</code></a> is a reserved attribute for identifying elements (without requiring a schema)</li>
					</ul>
				</ul>
				<listing src="blinkbase-i18n.xml" line="66-73"/>
			</slide>
        </part>
		<part id="i18n-uri">
			<title>URIs for Multilingual Resources</title>
			<slide>
				<title>Naming Language Variants</title>
				<ul>
					<li>URIs are intended to be names for resources (not for representations)</li>
					<ul>
						<li>when does a representation become an individual resource?</li>
						<li>the distinction is a gradual one (and it also applies to versioning over time)</li>
						<li>if I send you a bookmark of a german page, should you get an english variant?</li>
					</ul>
					<li>Advantages when language variants are different resources</li>
					<ul>
						<li>language variants can be identified (e.g., bookmarked) reliably</li>
					</ul>
					<li>Advantages when language variants are the same resource</li>
					<ul>
						<li>when accessing the resource, a more appropriate variant can be negotiated dynamically</li>
					</ul>
					<li>Ideally, language variants should use a mix of both approaches</li>
					<ul>
						<li>have their own URI so that they can be bookmarked and handled individually</li>
						<li>remain identifiable as a variant of the more generic <q>language-independent resource</q></li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Variant Naming Variations</title>
				<ul>
					<li>URIs can be used in a number of different ways</li>
					<ul>
						<li>any Web-based publishing should have a strategy for using URIs</li>
						<li>being consistent is almost as important as doing it right</li>
					</ul>
					<li>For variations of URIs, various parts of the Web architecture can be used</li>
					<ul>
						<li>DNS names for naming servers</li>
						<li>various parts of the URI name</li>
						<li>protocol mechanisms of HTTP or <link href="cookie"/>s</li>
						<li><a href="http://h3h.net/2007/01/designing-urls-for-multilingual-web-sites/">Designing URLs for Multilingual Web Sites</a> lists a number of possible variations</li>
					</ul>
				</ul>
			</slide>
			<slide id="lang-variant-dns-domains">
				<title>DNS Domains</title>
				<pre>http://<span style="color : red">en.</span>example.com/foo/bar</pre>
				<ul>
					<li>Defines DNS subdomains for all supported languages</li>
					<li>Advantages</li>
					<ul>
						<li>offers easy load-balancing to different servers (but code must kept in sync)</li>
						<li>bookmarks identify the language variant</li>
					</ul>
					<li>Disadvantages</li>
					<ul>
						<li>no easy way to get from one variant to another in terms of <q>URI navigation</q></li>
						<li>language management requires DNS updates</li>
						<li>DNS names have not been designed for this kind of usage</li>
					</ul>
				</ul>
			</slide>
			<slide id="lang-variant-path-segment">
				<title>Constructed Paths</title>
				<pre>http://example.com/<span style="color : red">en/</span>foo/bar</pre>
				<ul>
					<li>Encodes the language as the first path segment of the URI path</li>
					<li>Advantages</li>
					<ul>
						<li>bookmarks identify the language variant</li>
					</ul>
					<li>Disadvantages</li>
					<ul>
						<li>logically, the URI path does not represent the hierarchy of resources</li>
						<li>no easy way to get from one variant to another in terms of <q>URI navigation</q></li>
						<li>hard to maintain if this is used as the actual layout of documents in directories</li>
					</ul>
				</ul>
			</slide>
			<slide id="lang-variant-query-string">
				<title>Query Strings</title>
				<pre>http://example.com/foo/bar<span style="color : red">?lang=en</span></pre>
				<ul>
					<li>Use a query string to get the language in the required language variant</li>
					<li>Advantages</li>
					<ul>
						<li>bookmarks identify the language variant</li>
						<li><code>http://example.com/foo/bar</code> is usable for the abstract resource</li>
					</ul>
					<li>Disadvantages</li>
					<ul>
						<li>does not allow proper caching of pages</li>
						<li>search engines ignore query strings and thus cannot link to the variants</li>
						<li>against the idea of query strings which are meant for dynamic content</li>
						<li>hard to combine with other query string information (if required)</li>
					</ul>
				</ul>
			</slide>
			<slide id="lang-variant-dns-tld">
				<title>DNS TLDs</title>
				<pre>http://example<span style="color : red">.us</span>/foo/bar</pre>
				<ul>
					<li>Use DNS TLDs to identify the supported languages</li>
					<li>Advantages</li>
					<ul>
						<li>bookmarks identify the language variant</li>
					</ul>
					<li>Disadvantages</li>
					<ul>
						<li>requires registration of many TLDs (effort, costs, domain squatting)</li>
						<li>countries do not identify languages (requires additional mechanism)</li>
						<li>because of the country/language complexity, cross-language links are hard to maintain</li>
						<li>DNS names have not been designed for this kind of usage</li>
					</ul>
				</ul>
			</slide>
			<slide id="lang-variant-cookie">
				<title>Cookies</title>
				<pre>http://example.com/foo/bar</pre>
				<ul>
					<li>Store the cookie with the language preference and use the cookie setting</li>
					<li>Advantages</li>
					<ul>
						<li>language is not part of the URI and thus the URI identifies the resource</li>
						<li>bookmarks (and any intra-page links) will automatically yield the preferred language variant</li>
					</ul>
					<li>Disadvantages</li>
					<ul>
						<li>does not work if <link href="cookie"/>s are disabled or intercepted</li>
						<li>it is not possible to create a bookmark for the language variant</li>
					</ul>
				</ul>
			</slide>
			<slide id="lang-variant-http">
				<title>Content Negotiation</title>
				<pre>http://example.com/foo/bar</pre>
				<ul>
					<li>Use browser settings and <link href="http-content-negotiation"/> to get the variant</li>
					<li>Advantages</li>
					<ul>
						<li>language is not part of the URI and thus the URI identifies the resource</li>
						<li>bookmarks (and any intra-page links) will automatically yield the preferred language variant</li>
					</ul>
					<li>Disadvantages</li>
					<ul>
						<li>does not work if the user agent does not support <link href="http-content-negotiation"/></li>
						<li>does not work if the user has not configured the browser correctly</li>
						<li>switching between languages requires configuration of the browser</li>
						<li>it is not possible to create a bookmark for the language variant</li>
					</ul>
				</ul>
			</slide>
			<slide id="lang-variant-extension">
				<title>Path Segment Name</title>
				<pre>http://example.com/foo/bar<span style="color : red">.en</span></pre>
				<ul>
					<li>Use <q><code>.</code></q> which uses the resource's <q>extension</q></li>
					<li>Advantages</li>
					<ul>
						<li>bookmarks identify the language variant</li>
						<li>maps easily to extensions in file systems</li>
					</ul>
					<li>Disadvantages</li>
					<ul>
						<li>does not mix well if additional properties (such as the format) are required</li>
						<li>no easy way to get from one variant to another in terms of <q>URI navigation</q></li>
						<li>not officially recognized as URI structure (just simplifies parsing and recognition)</li>
					</ul>
				</ul>
			</slide>
			<slide id="lang-variant-comma">
				<title>URI Sub-Delimiter Comma</title>
				<pre>http://example.com/foo/bar<span style="color : red">,en</span></pre>
				<ul>
					<li>Use <q><code>,</code></q> for specifying a parameter to a URI <em>path segment</em></li>
					<li>Advantages</li>
					<ul>
						<li>bookmarks identify the language variant</li>
						<li>makes the language identifiable as a special part of the URI</li>
						<li><code>http://example.com/foo/bar</code> is usable for the abstract resource</li>
					</ul>
					<li>Disadvantages</li>
					<ul>
						<li>does not mix well with parameters for other resource dimensions</li>
						<li>not officially recognized as URI structure (just simplifies parsing and recognition)</li>
					</ul>
				</ul>
			</slide>
			<slide id="lang-variant-semicolon">
				<title>URI Sub-Delimiter Semicolon</title>
				<pre>http://example.com/foo/bar<span style="color : red">;lang=en</span></pre>
				<ul>
					<li>Use <q><code>;</code></q> for specifying a parameter to a URI <em>path segment</em></li>
					<li>Advantages</li>
					<ul>
						<li>bookmarks identify the language variant</li>
						<li>makes the language identifiable as a special part of the URI</li>
						<li>can be combined with parameters for other resource dimensions</li>
						<li><code>http://example.com/foo/bar</code> is usable for the abstract resource</li>
					</ul>
					<li>Disadvantages</li>
					<ul>
						<li>not officially recognized as URI structure (just simplifies parsing and recognition)</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Now What?</title>
				<ul>
					<li>There is no perfect solution for naming language variants</li>
					<ul>
						<li>the Web architecture does not provide support for <q>variant preference</q> in a URI</li>
						<li>there is a strong separation between static URIs and dynamic content negotiation</li>
					</ul>
					<li>The name-based solutions (using <q><code>.</code></q>, <q><code>;</code></q>, and <q><code>,</code></q>) are very similar</li>
					<ul>
						<li>any difference between them is how they are used in practice</li>
						<li>from the URI point of view, path segments containing <q><code>.</code></q>, <q><code>;</code></q>, and <q><code>,</code></q> are not treated in any special way</li>
						<li>the only officially recognized special path segments are <q><code>.</code></q> and <q><code>..</code></q></li>
					</ul>
					<li>Theoretically, HTTP could define scheme-specific semantics</li>
					<ul>
						<li>for <code>http</code> URIs, <q><code>,</code></q> and/or <q><code>;</code></q> could interact with content negotiation</li>
						<li>while this is an interesting idea with many useful applications, it is very unlikely to happen</li>
					</ul>
					<li>Use <link href="lang-variant-comma"><q><code>,</code></q></link> or <link href="lang-variant-semicolon"><q><code>;</code></q></link> for language variants, but do not expect magic to happen</li>
				</ul>
			</slide>
		</part>
        <part>
			<title>Conclusions</title>
			<slide>
				<title>Babelification</title>
				<ul>
					<li>I18N is a non-trivial task and requires some planning</li>
					<li>L10N involves much more than just translating text</li>
					<li>Producing fully localized products is a complex issue</li>
					<li>The <em>locale</em> is based on language and culture and customs</li>
					<li>Successful L10N requires the input of local people</li>
				</ul>
			</slide>
        </part>
    </presentation>
    <presentation id="pictures">
        <title short="Pictures">Picture Formats</title>
        <date>2007-10-25</date>
        <toc class="resources"><a href="http://www.w3.org/Graphics/GIF/spec-gif89a.txt" title="GIF Spec">GIF</a>&#160;· <a href="http://www.w3.org/Graphics/JPEG/" title="JFIF Spec">JPEG</a>&#160;· <a href="http://www.w3.org/TR/PNG/" title="W3C PNG Spec">PNG</a></toc>
        <toc class="abstract">Pictures are the only multimedia content on the Web that is widely supported by standardized formats. The most important picture formats are the <em>Graphics Interchange Format</em>, the <em>Joint Photographic Experts Group (JPEG)</em> format, and the <em>Portable Network Graphics (PNG)</em> format. These picture formats target different application areas and depending on the picture material, choosing one format over the other can make a big difference.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<slide id="picture-formats">
			<title>Images vs. Graphics</title>
			<ul>
				<li><em>Images</em> are bitmaps of pixels that represent a picture</li>
				<ul>
					<li>it takes some kind of <em>scanning process</em> to produce images</li>
					<li>images have a certain <em>resolution</em> based on the quality of the scanning process</li>
					<li>scanning can take place in a scanner, in a fax machine, or in a camera's CCD</li>
				</ul>
				<li><em>Graphics</em> are composed out of graphic primitives</li>
				<ul>
					<li>graphics can be searchable, stylable, and scalable</li>
					<li>the graphics format can have very different capabilities (2D vs. 3D)</li>
				</ul>
				<li>Graphics preserve model-level information</li>
				<ul>
					<li>this only makes sense if there <em>is</em> a model</li>
					<li>rendering and styling can be an expensive process (e.g., video games)</li>
					<li>images can be a snapshot of some specific <q>view</q> of graphics</li>
				</ul>
				<li>Today's Web supports images, but not graphics</li>
			</ul>
		</slide>
		<part id="image-formats">
			<title>Image Formats</title>
			<part id="gif">
				<title short="GIF">Graphics Interchange Format (GIF)</title>
				<slide>
					<title short="GIF">Graphic Interchange Format (GIF)</title>
					<ul>
						<li><a href="http://dret.net/rfc-index/reference/RFC2046">RFC 2046</a> registers the oldest graphics format on the Web</li>
						<li>GIF was subject of a long patent debate</li>
						<ul>
							<li>the compression technique of GIF (<a href="http://dret.net/glossary/lzw" title="Lempel-Ziv-Welch">LZW</a>) had been patented by Unisys (1983)</li>
							<li>Unisys wanted to get licensing fees from all commercial online uses of GIF</li>
							<li><link href="png"/> was developed as an effort to develop a copyright-free format</li>
							<li>in 1999, Unisys changed its tactics and wanted to collect one-time fees ($5000-$7500) from all users</li>
							<li>all GIF-related LZW expired in 2003/2004, so GIF is freely available now</li>
						</ul>
						<li>GIF's poor features make PNG the better choice anyway</li>
						<ul>
							<li>8 bit color (requires dithering for photographs), binary transparency</li>
							<li>GIF's animation feature is the only thing that is not available in PNG … <img src="running-wolf.gif" style="height : 0.8em"/></li>
						</ul>
					</ul>
				</slide>
			</part>
			<part id="jpeg-group">
				<title short="JPEG">Joint Photographic Experts Group (JPEG)</title>
				<slide id="jpeg">
					<title short="JPEG">Joint Photographic Experts Group (JPEG)</title>
					<ul>
						<li><a href="http://dret.net/rfc-index/reference/RFC2046">RFC 2046</a> standardizes the second popular image format for the Web</li>
						<ul>
							<li><a href="http://dret.net/biblio/reference/iso10918">ISO 10918</a> is the standard for the actual image format</li>
						</ul>
						<li>JPEG has been specifically designed for photographs</li>
						<ul>
							<li>it always is lossy (it cannot preserve the complete information from a random bitmap)</li>
							<li>it uses perception-based compression (for example, color precision is sacrificed for brightness)</li>
						</ul>
					</ul>
					<table style="width : 90% ; margin : 4% ;  font-size : smaller ; ">
						<tr>
							<td align="center">
								<img src="jpeg-average-quality.jpg" title="Average Quality JPEG" href="http://en.wikipedia.org/wiki/JPEG#Photographs"/>
							</td>
							<td align="center">
								<img src="jpeg-low-quality.jpg" title="Low Quality JPEG" href="http://en.wikipedia.org/wiki/JPEG#Photographs"/>
							</td>
							<td align="center">
								<img src="jpeg-lowest-quality.jpg" title="Lowest Quality JPEG" href="http://en.wikipedia.org/wiki/JPEG#Photographs"/>
							</td>
						</tr>
						<tr>
							<th>Q = 50, filesize 15,138 bytes</th>
							<th>Q = 10, filesize 4,787 bytes</th>
							<th>Q = 1, filesize 1,523 bytes</th>
						</tr>
					</table>
				</slide>
				<slide id="jpeg2000">
					<title>JPEG 2000</title>
					<ul>
						<li>JPEG has some problems (for example, it is never lossless)</li>
						<ul>
							<li>compression technology has advanced since JPEG (<a href="http://www.acm.org/crossroads/xrds6-3/sahaimgcoding.html">DCT → Wavelets</a>)</li>
						</ul>
						<li><em>JPEG 2000</em> is a completely new standard</li>
						<ul>
							<li>it uses wavelets instead of DCT as the compression algorithm</li>
							<li>it includes support for lossless encoding (JPEG is always lossy)</li>
							<li>it even comes with its own transmission protocol (<a href="http://dret.net/glossary/jpip" title="JPEG 2000 Interactive Protocol">JPIP</a>)</li>
							<li><mime>image/jp2</mime> (<a href="http://dret.net/glossary/jp2">JP2</a>) and <mime>image/jpx</mime> (<a href="http://dret.net/glossary/jpx">JPX</a>) are the two JPEG 2000 MIME types</li>
						</ul>
						<li>Support for JPEG 2000 is good but not universal</li>
					</ul>
				</slide>
			</part>
			<part id="png">
				<title short="PNG">Portable Network Graphics (PNG)</title>
				<slide>
					<img src="png-transparency.png" style="float : right ; "/>
					<title short="PNG">Portable Network Graphics (PNG)</title>
					<ul>
						<li>PNG is registered as <mime>image/png</mime> and is the third major image format</li>
						<ul>
							<li>PNG was intended to be a royalty- and copyright-free replacement of <link href="gif">GIF</link></li>
							<li>image formats need to supported by browsers and thus take a long time until they are established</li>
							<li>IE6 implements PNG in a very rudimentary form, IE7 handles PNG correctly</li>
						</ul>
						<li>PNG has some advantages over GIF and JPEG</li>
						<ul>
							<li>lossless, compressed palette, grayscale, or true color images</li>
							<li>8 bit alpha channel for gradual opacity (blending into the background)</li>
						</ul>
						<li>JPEG still is the preferred format for photographic pictures</li>
						<li>GIF still is the preferred format for animated images</li>
						<ul>
							<li><a href="http://dret.net/glossary/mng" title="Multiple-image Network Graphics">MNG</a> and <a href="http://dret.net/glossary/apng" title="Animated Portable Network Graphics">APNG</a> are two available but not widely supported PNG animation formats</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Alpha Channel Effects</title>
					<table width="90%">
						<tr>
							<tr>
								<td style="background : #000000"><img src="png-transparency.png"/></td>
								<td style="background : #404040"><img src="png-transparency.png"/></td>
								<td style="background : #606060"><img src="png-transparency.png"/></td>
							</tr>
							<tr>
								<td style="background : #808080"><img src="png-transparency.png"/></td>
								<td style="background : #A0A0A0"><img src="png-transparency.png"/></td>
								<td style="background : #C0C0C0"><img src="png-transparency.png"/></td>
							</tr>
						</tr>
					</table>
				</slide>
			</part>
			<part>
				<title>Other Image Formats</title>
				<slide id="tiff">
					<title short="TIFF">Tagged Image File Format (TIFF)</title>
					<ul>
						<li>Standard file format format for scanned images</li>
						<ul>
							<li>none of the limitations of <link href="gif"/></li>
							<li>ability to represent any kind of bitmapped image information</li>
							<li>compression is supported but always lossless (not as effective as <link href="jpeg">JPEG</link>)</li>
						</ul>
						<li>Popular for scanned images and similar applications</li>
						<ul>
							<li>native support in browsers is the exception (only Safari)</li>
						</ul>
					</ul>
				</slide>
				<slide id="ico">
					<title>Icons</title>
					<ul>
						<li>Original <em>favicon</em> (a.k.a. <em>page icon</em> or <em>urlicon</em>) format</li>
						<ul>
							<li>the image format used by Windows for its icons (which is identical to the cursor format)</li>
						</ul>
						<li>Important on the Web only for Web site icons</li>
						<ul>
							<li>most browsers will display the icons in the address bar</li>
							<li>most browsers will remember the icon for bookmarks and shortcuts</li>
						</ul>
						<li>Icons appear as meta information of a Web page</li>
						<ul>
							<li>standards are not really tight and based on best practices and browsers</li>
						</ul>
						<pre><![CDATA[<link rel="icon" href="/favicon.ico" type="image/x-icon" />
<link rel="shortcut icon" href="/favicon.ico" type="image/x-icon" />]]></pre>
					</ul>
				</slide>
			</part>
		</part>
		<part id="graphics-formats">
			<title>Graphics Formats</title>
			<slide>
				<title>Image Concepts</title>
				<ul>
					<li>Pictures of the real world are always lossy</li>
					<ul>
						<li>there is no (accessible) underlying <q>model</q> of the real world</li>
						<li>the real world is always pictured as well as technically possible</li>
					</ul>
					<li>Graphics start from some model and turn that into an image</li>
					<ul>
						<li>an <em>image</em> of a circle will always appear jagged on close inspection</li>
						<li>a graphical picture of a circle is always perfectly round</li>
					</ul>
					<li>Graphics can be customized based on presentation needs</li>
					<ul>
						<li>line and text color can be coordinated with the rest of Web page design</li>
						<li>any information can be used as input to the graphics → image conversion</li>
					</ul>
					<li>Graphics can be searched for concepts and contents</li>
				</ul>
			</slide>
			<part id="svg">
				<title>Scalable Vector Graphics (SVG)</title>
				<slide>
					<title>Graphics for the Web</title>
					<ul>
						<li>Identified as <q>important media type</q> a long time ago</li>
						<ul>
							<li>W3C work on SVG for a long time</li>
							<li>complex format with little support and little success on the Web</li>
						</ul>
						<li>Embedding SVG in HTML <a href="http://www.carto.net/papers/svg/samples/svg_html.shtml">is more art than science</a></li>
						<ul>
							<li>using SVG requires browser-specific HTML code</li>
							<li>backwards compatibility must support bitmapped version of the SVG pictures</li>
						</ul>
						<li>Support for SVG is provided by many newer tools</li>
						<ul>
							<li>the SVG code produced not always is a very good version of SVG</li>
							<li>SVG has not yet been adopted as something that people really care about</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Image vs. Graphics</title>
					<table width="90%">
						<tr>
							<td><img src="svg.png"/></td>
							<td><object type="image/svg+xml" data="img/svg.svg"/></td>
						</tr>
					</table>
				</slide>
			</part>
		</part>
        <part>
			<title>Conclusions</title>
			<slide>
				<title>Multimedia on the Web</title>
				<ul>
					<li>Images are the only supported media types on the Web</li>
					<li>Graphics and video and audio are not universally supported</li>
					<li>Image formats serve different purposes on the Web</li>
					<li>PNG for graphics and JPEG for photographic images</li>
					<li>GIF should be avoided (still required for animated images)</li>
				</ul>
			</slide>
        </part>
    </presentation>
    <presentation id="syndication">
        <title short="Syndication">Content Syndication</title>
        <date>2007-10-30</date>
        <toc class="reading"><a href="http://www.xml.com/pub/a/2004/08/18/pilgrim.html">Identifying Atom</a></toc>
        <toc class="resources"><a href="http://atompub.org/rfc4287.html" title="Atom RFC">Atom</a>&#160;· <a href="http://atompub.org/rfc5032.html" title="Atom Publishing Protocol (AtomPub) RFC">AtomPub</a>&#160;· <a href="http://validator.w3.org/feed/" title="W3C RSS/Atom Feed Validator">Validator</a></toc>
        <toc class="abstract">For many information sources on the Web, it is useful to have some standardized way of subscribing to information updates. Syndication formats such as  <em>RSS</em> and <em>Atom</em> can be used by these information sources to publish a <em>feed</em> of updated information items. While RSS and Atom are read-only formats, the <em>Atom Publishing Protocol (AtomPub)</em> build on top of Atom and provides a protocol for submitting new items to feeds.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<slide>
			<title>Content Feeds</title>
			<ul>
				<li>Early Web content was static or updated very infrequently</li>
				<ul>
					<li>there was not yet the requirement to reuse content in different contexts</li>
				</ul>
				<li>Frequently updated Web content quickly became a very common scenario</li>
				<ul>
					<li>as commercial interests took over the Web, users should have a reason to re-visit a site</li>
					<li>presenting a steady stream of new content creates the image of a live Web site</li>
				</ul>
				<li>There are two major use cases where HTML is not sufficient</li>
				<ol>
					<li>users want an efficient way to get the updated content from a site</li>
					<li>sites want to aggregate updated content from other sites and re-publish it</li>
				</ol>
				<li><link href="syndication-formats"/> are designed to support these two use cases</li>
				<ul>
					<li>container formats for updated items</li>
					<li>a small amount of metadata about these items for automated processing</li>
				</ul>
			</ul>
		</slide>
		<part id="syndication-formats">
			<title>Syndication Formats</title>
			<part id="rss">
				<title>RSS</title>
				<slide id="rss-versions">
					<title>RSS History</title>
					<ul>
						<li><q><a href="http://diveintomark.org/archives/2004/02/04/incompatible-rss">The Myth of RSS Compatibility</a></q> provides a good overview</li>
						<li>RSS is a schoolbook example for <q>why standards are a good thing</q></li>
						<ul>
							<li><link href="rss09"/> was created for the <em>My Netscape</em> portal in March 1999</li>
							<li>RSS 0.91 (a simplification) was introduced in July 1999 (as an interim solution)</li>
							<li>the AOL/Netscape merger removed the format from the company's portal</li>
							<li>RSS was without an owner, and different parties claimed/denied ownership</li>
							<li><link href="rss10"/> was created by an informal developer group</li>
							<li>RSS 0.92 (and 0.93 and 0.94) were published without acknowledging RSS 1.0</li>
							<li>finally, <link href="rss20"/> was released as a follow-up to the RSS 0.9x versions</li>
						</ul>
						<li>Using RSS has become an exercise in managing a menagerie of versions</li>
					</ul>
				</slide>
				<slide id="rss09">
					<title>RSS 0.9</title>
					<ul>
						<li>RSS means <em>RDF Site Summary</em> (or <em>Rich Site Summary</em>?)</li>
						<ul>
							<li>based on an RDF draft and not compatible with the final RDF specification</li>
							<li>RDF was considered too cumbersome and unstable</li>
							<li>0.90 (proto-RDF) was quickly replaced by the non-RDF 0.91 version</li>
						</ul>
						<li>RSS 0.92+ versions were developed as unilateral specifications</li>
						<ul>
							<li>starting with RSS 0.91, RSS means <em>Rich Site Summary</em></li>
							<li>it is no longer built on RDF, instead it simply uses XML</li>
							<li>the 0.9x branch eventually was renamed to <link href="rss20"/></li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>RSS 0.91 Example</title>
					<listing src="rss091.xml" line="2-12" href="http://www.xml.com/pub/a/2002/12/18/dive-into-xml.html"/>
				</slide>
				<slide id="rss10">
					<title>RSS 1.0</title>
					<ul>
						<li>RSS means <em>RDF Site Summary</em> (this time for real)</li>
						<ul>
							<li>based on the final RDF specification and thus incompatible with any <link href="rss09"/></li>
							<li>developed when the <link href="semweb"/> and <link href="rdf">RDF</link> were first heavily marketed (<a href="http://dret.net/biblio/reference/lee99" title='Tim Berners-Lee, Mark Fischetti, Michael Dertouzos, "Weaving the Web", HarperCollins, 1999'>1999</a>)</li>
							<li>RDF was expected to become the format for metadata on the Web</li>
						</ul>
						<li>RSS 1.0 makes heavy use of XML Namespaces</li>
						<li>RSS 1.0 introduces features which were not present in 0.91</li>
						<ul>
							<li>date information for published items (very relevant for news feeds)</li>
							<li>individual authors for various items in a feed</li>
						</ul>
						<li>RSS 1.0 is the latest version of RDF-based RSS</li>
						<ul>
							<li>the Semantic Web wave is not over yet, but RDF has lost its novelty appeal</li>
							<li>for a more XML-oriented encoding, <link href="rss09"/> provides a better foundation</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>RSS 1.0 Example</title>
					<listing src="rss10.xml" line="2-22" href="http://www.xml.com/pub/a/2002/12/18/dive-into-xml.html"/>
				</slide>
				<slide id="rss20">
					<title>RSS 2.0</title>
					<ul>
						<li>RSS now means <em>Really Simple Syndication</em></li>
						<ul>
							<li>RSS 2.0 is the continuation of the 0.91 branch (which dropped RDF)</li>
							<li>together with <link href="rss10"/> it is the most popular version of RSS</li>
							<li>migration from 0.91 to 2.0 is easily possible</li>
						</ul>
						<li>RSS 2.0 tries to avoid the use of XML Namespaces</li>
						<li>RSS 2.0 is <a href="http://rss-extensions.org/wiki/Main_Page">increasingly used with extensions</a> for vendor-specific information</li>
						<ul>
							<li>the RSS core is minimal, so many applications need extensions</li>
							<li>many extensions have overlapping functionality</li>
							<li>most extensions have unclear semantics and unclear versioning policies</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>RSS 2.0 Example</title>
					<listing src="rss20.xml" line="2-14" href="http://www.xml.com/pub/a/2002/12/18/dive-into-xml.html"/>
				</slide>
				<slide>
					<title>The Case for Content Management</title>
					<ul>
						<li>RSS is very rarely produced by hand</li>
						<ul>
							<li>by definition, RSS contains redundant information for a specific purpose</li>
						</ul>
						<li>If a <em>Content Management System (CMS)</em> is used, RSS can be generated</li>
						<ul>
							<li>basic metadata can be generated by the CMS (title, author, date)</li>
							<li>better tagging of content results in better tagging of feeds</li>
							<li>well-tagged feeds are better foundations for large-scale reuse of feed items</li>
						</ul>
						<li>Blogging is simply a specialized case of a CMS</li>
						<ul>
							<li>Web-based interface for controlling everything</li>
							<li>strictly time-ordered sequenced of published items</li>
							<li>navigation features primarily based on the time-specific facets of the blog (maybe tags)</li>
							<li>all blogging tools include feed support</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Consuming RSS</title>
					<ul>
						<li>RSS feeds often have quality problems</li>
						<ul>
							<li>surprisingly often feeds do not even deliver well-formed XML</li>
							<li>the use of embedded markup in RSS is not well-defined</li>
						</ul>
						<li>Writing an RSS reader from scratch is not a good idea</li>
						<li>There are three major tasks which RSS readers must do</li>
						<ol>
							<li>accept non-XML RSS feeds and fix them to be XML</li>
							<li>look at the feed contents and bring them into a unified form</li>
							<li>produce a unified view of feeds regardless of the RSS version</li>
						</ol>
					</ul>
				</slide>
				<slide>
					<title>RSS Technical Problems</title>
					<ul>
						<li>What to put into an item's description</li>
						<ul>
							<li>the fundamental question is whether a description is text or HTML</li>
							<li>if there is no well-defined way, then interpretation is client-specific</li>
							<pre>&lt;description>This is a &lt;em>very important&lt;/em> blog post …</pre>
							<pre>&lt;description>This is a &amp;lt;em>very important&amp;lt;/em> blog post …</pre>
							<pre>&lt;description>This is a blog post about &lt;em> in RSS feeds …</pre>
							<pre>&lt;description>This is a blog post about &amp;lt;em> in RSS feeds …</pre>
							<pre>&lt;description>This is a blog post about &amp;amp;lt;em> in RSS feeds …</pre>
						</ul>
						<li>Underspecified and not very robust in various other areas</li>
						<ul>
							<li>broken RSS is accepted by most readers (but fixing it can change the interpretation)</li>
							<li>the interpretation of relative URIs is not mentioned in the specifications</li>
							<li>some minimal semantics (classification) for items would be very useful</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>RSS Political Problems</title>
					<ul>
						<li>Multiple and incompatible <link href="rss-versions"/> are still in widespread use</li>
						<ul>
							<li><link href="rss10"/> and <link href="rss20"/> are <q>incompatible by design</q> (RDF vs. non-RDF)</li>
							<li>none of the RSS versions is maintained by a universally accepted standards body</li>
						</ul>
						<li>None of the specifications is being updated or fixed</li>
						<ul>
							<li>some of the lessons learned by RSS deployment are not used in a new version</li>
							<li>it is unlikely that a new version will be produced which merges the RSS landscape</li>
						</ul>
						<li>Invent something new instead of trying to fix RSS</li>
						<ul>
							<li><link href="atom"/> started in 2003 (called <em>Echo</em> at first)</li>
							<li>W3C or IETF would have been promising candidates for a <q>new RSS</q></li>
							<li>W3C is more formal, IETF is more developer-centered</li>
							<li><a href="http://www.bestkungfu.com/?p=492">IETF was chosen over W3C</a> because the of Atom community's preferences</li>
						</ul>
					</ul>
				</slide>
			</part>
			<part id="atom">
				<title>Atom</title>
				<slide>
					<title>Atom History</title>
					<img src="atom-logo.png" href="http://atompub.org/" style="float : right ; margin-top : 0.5em ; margin-right : 2em ; "/>
					<ul>
						<li>RSS's shortcomings were very apparent and could not be fixed</li>
						<li>In mid-2003, discussions started about an improved format</li>
						<li>It also became apparent that the format should have a protocol</li>
						<li>Atom 0.3 was released in December 2003 but had no formal home</li>
						<li>IETF was chosen as the new home with a working group in June 2004</li>
						<li><a href="http://dret.net/rfc-index/reference/RFC4287">RFC 4287</a> was published in December 2005</li>
						<li><link href="atompub">AtomPub</link> has been published as <a href="http://dret.net/rfc-index/reference/RFC5032">RFC 5032</a> in October 2007</li>
					</ul>
				</slide>
				<slide>
					<title>Atom vs. RSS</title>
					<ul>
						<li>Standardized by the IETF (well-defined process)</li>
						<li>Classification of entries (user-defined categories)</li>
						<li>More XML-like markup design (more nesting)</li>
						<li>Namespaces are used and supported as standard mechanism</li>
						<li>Atom feeds <em>must</em> be well-formed XML (there even <a href="http://atompub.org/2005/08/17/atom.rnc" title="Atom RELAX NG Schema">is a schema</a>)</li>
						<li>Interpretation of content is well-defined (various content types)</li>
						<li>Support for <code>xml:lang</code> and <code>xml:base</code></li>
					</ul>
				</slide>
				<slide>
					<title>Atom Example</title>
					<listing src="atom.xml"/>
				</slide>
				<slide>
					<title>Atom Content</title>
					<ul>
						<li>RSS had no safe way of finding out what an entry's content is</li>
						<ul>
							<li>this led to different implementations using <q>smart ways</q> of what the RSS author really wanted</li>
							<li>one of Atom's main goals was to improve this in a well-defined way</li>
							<li>Atom allows escaped markup (the only way to include non-XML HTML in an XML format)</li>
						</ul>
						<li>Each <elem>content</elem> element should have a <atom>type</atom> (the default is <code>text</code>)</li>
						<li>Atom's content interpretation algorithm (use first applicable rule):</li>
						<ol>
							<li>if <atom>type</atom> is <code>text</code>, no child elements are allowed (plain text content)</li>
							<li>if <atom>type</atom> is <code>html</code> then RSS's method of escaped markup is used</li>
							<li>if <atom>type</atom> is <code>xhtml</code> then there must be an <elem>div</elem> containing XHTML markup</li>
							<li>if <atom>type</atom> is an XML <link href="mime">MIME type</link> then the content should be treated as this type</li>
							<li>if <atom>type</atom> starts with <code>text/</code> then no child elements are allowed</li>
							<li>for all other values, the content must be an base64-encoded entity of the specified MIME type</li>
						</ol>
					</ul>
				</slide>
				<slide>
					<title>Atom Content Examples</title>
					<pre href="http://www.xml.com/lpt/a/1633"><![CDATA[<content type="xhtml">
  <div xmlns="http://www.w3.org/1999/xhtml">
    One <strong>bold</strong> foot forward
  </div>
</content>]]></pre>
					<pre href="http://www.xml.com/lpt/a/1633"><![CDATA[<content>The "atom:content" element either contains or links to the content of the entry. The content of atom:content is Language-Sensitive.</content>]]></pre>
					<pre href="http://www.xml.com/lpt/a/1633"><![CDATA[<content type="html">The &lt;code>atom:content&lt;/code> element either contains or links to the content of the entry. The content of &lt;code>atom:content&lt;/code> is &lt;a href="http://www.ietf.org/rfc/rfc3066.txt">Language-Sensitive&lt;/a>.</content>]]></pre>
					<pre href="http://www.xml.com/lpt/a/1633"><![CDATA[<content type="image/png">
iVBORw0KGgoA … TAAAAAElFTkSuQmCC
</content>]]></pre>
					<pre href="http://www.xml.com/lpt/a/1633"><![CDATA[<content src="image.png" type="image/png"/>]]></pre>
				</slide>
				<slide>
					<title>Atom Categories</title>
					<ul>
						<li>Atom allows to assign categories to entries</li>
						<ul>
							<li>each <elem>category</elem> element must have a <atom>term</atom> attribute for the category</li>
							<li>an optional <atom>scheme</atom> identifies the categorization scheme (ontology, taxonomy, …)</li>
							<li>an optional <atom>label</atom> attribute provides a human-readable label for the category</li>
						</ul>
						<li><link href="atompub">AtomPub</link> defines a document format for <link href="atom-category-documents"/></li>
						<li>Three different cases of categorization can be distinguished</li>
						<ol>
							<li>use a well-known scheme (such as <em>Dublin Core</em>)</li>
							<li>use a private but well-designed scheme (which has a URI and can be reused reliably)</li>
							<li>use tags without schemes, which then are little more than content labels</li>
						</ol>
						<li>Widely-known tags are <a href="http://www.tbray.org/ongoing/When/200x/2007/02/01/Tag-Scheme">not easy to handle</a></li>
						<ul>
							<li>they are more than just privately assigned tags</li>
							<li>there is no formal scheme for them, just an emerging consensus</li>
						</ul>
					</ul>
				</slide>
				<slide>
					<title>Switching from RSS to Atom</title>
					<ul>
						<li>Generate both feeds but serve RSS with a HTTP redirect (301)</li>
						<ul>
							<li>old subscribers with broken clients can still use the RSS feed</li>
							<li>old subscribers with correct clients will use the Atom feed</li>
						</ul>
						<li>Atom exposes more information than RSS (<elem>category</elem> for tags)</li>
						<ul>
							<li>the mapping of publishing info to the feed has to be changed/extended</li>
							<li>for standard metadata use Atom's built-in metadata elements</li>
							<li>for application-specific metadata consider reusing an existing metadata schema</li>
						</ul>
						<li>Atom can be used to publish snippets as well as full content</li>
						<ul>
							<li><elem>content</elem> allows any type of content to be used and may contain a complete entry</li>
							<li><elem>summary</elem> allows only text and should provide a condensed version of an entry</li>
							<li>some Atom sources publish two feeds for summaries and content</li>
						</ul>
						<li>Generate good Atom and downgrade it to RSS 1.0 &amp; 2.0</li>
					</ul>
				</slide>
			</part>
		</part>
		<part>
			<title>Syndication Aggregation</title>
			<slide>
				<title>End-User Aggregation</title>
				<img src="feed-icon.png" style="float : right ; margin-top : 0.5em ; margin-right : 2em ; "/>
				<ul>
					<li>Users often have a small number of preferred Web sites</li>
					<ul>
						<li>news can be tracked by subscribing to their feeds</li>
						<li>this requires an RSS-aware client (Firefox is not a good RSS reader)</li>
					</ul>
					<li>AJAX-based RSS could be implemented as a client-side application</li>
					<ul>
						<li>retrieve the feed, transform it to HTML, and render the result</li>
						<li>but the security restriction of <code>XMLHttpRequest</code> gets into the way</li>
						<li>there is a way around this as used in the <a href="http://www-128.ibm.com/developerworks/library/x-ajaxrss/" title="IBM developerWorks Article by Jack D. Herrington">Ajax RSS reader</a></li>
					</ul>
					<li>How can users find a feed?</li>
					<ul>
						<li>feeds have URIs (they are Web resources) and can be referenced from within HTML</li>
					</ul>
				</ul>
				<pre>&lt;link rel="alternate" type="application/rdf+xml" title="…" href="…" />
&lt;link rel="alternate" type="application/rss+xml" title="…" href="…" /></pre>
				<pre>&lt;link rel="alternate" type="application/atom+xml" title="…" href="…" /></pre>
			</slide>
			<slide>
				<title>Aggregation Intermediaries</title>
				<div style="float : right ; width : 20% ; margin-right : 1.5em">
					<script type="text/javascript" src="http://www.google.com/reader/ui/publisher.js"></script>
					<script type="text/javascript" src="http://www.google.com/reader/public/javascript/user/16601496766743088901/state/com.google/broadcast?n=5&amp;callback=GRC_p(%7Bc%3A'gray'%2Ct%3A'Shared%20items'%2Cs%3A'true'%7D)%3Bnew%20GRC"></script>
				</div>
				<ul>
					<li>RSS is a frequently used format between content providers</li>
					<ul>
						<li>news agencies want to distribute news items as easy as possible</li>
						<li>by using a single format, producers and consumers can more easily interoperate</li>
					</ul>
					<li>The <link href="rss-versions"/> caused publishers to look for something better</li>
					<ul>
						<li><link href="rss"/> had a head start and still is widely used</li>
						<li><link href="atom"/> is a much better format and will eventually replace RSS</li>
					</ul>
					<li>User-configured portals are the merger between both scenarios</li>
					<ol>
						<li>users select a number of feeds as their preferred information sources</li>
						<li>the feeds are presented on a <a href="http://www.google.com/reader/view/" title="Google Reader">single personalized Web page</a></li>
						<li>by <a href="http://www.google.com/reader/shared/16601496766743088901" title="dret's Google Reader Shared Items">sharing</a> and <a href="http://www.google.com/reader/public/atom/user/16601496766743088901/state/com.google/broadcast" title="dret's Google Reader Atom Feed">re-publishing</a> items, users are becoming aggregation intermediaries</li>
					</ol>
				</ul>
			</slide>
		</part>
		<part id="atompub">
			<title>Atom Publishing Protocol</title>
			<slide>
				<title>Syndication Format Protocols</title>
				<ul>
					<li>LiveJournal (very simple text-based protocol)</li>
					<ul>
						<li>not very good at handling structures (re-inventing for encoding structure)</li>
					</ul>
					<li>Blogger (now at <a href="http://code.google.com/apis/blogger/overview.html">Google</a> after <a href="http://web.archive.org/web/20031008161432/http://weblog.siliconvalley.com/column/dangillmor/archives/000802.shtml">Google bought Pyra</a>)</li>
					<ul>
						<li>no support for titles or any other sort of entry metadata</li>
						<li>protocol from the early days of blogging before tagging became popular</li>
					</ul>
					<li><a href="http://www.xmlrpc.com/metaWeblogApi">MetaWeblog</a> (an attempt to improve Blogger)</li>
					<ul>
						<li>extends Blogger using a very bad design (RSS XML as XML-RPC structure encoded as XML)</li>
					</ul>
					<li><em>Atom Publishing Protocol (AtomPub)</em> is an attempt to provide a clean alternative</li>
					<ul>
						<li>use the same document structures for feeds and the protocol interacting with them</li>
						<li>use a REST approach to provide a simple and Web-compatible protocol</li>
						<li>add <link href="atom-service-documents"/> and <link href="atom-category-documents"/> for additional tasks</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>RESTified Syndication</title>
				<ul>
					<li>Atom is a format for retrieving a set of entries as a feed document</li>
					<ul>
						<li>feeds often are time-based and are refreshed periodically or whenever needed</li>
						<li>feeds can use any other strategy for deciding what to publish</li>
					</ul>
					<li>Read-only access to feeds should be complemented by full access</li>
					<ul>
						<li>full access needs the <q>CUD</q> out of the <q>CRUD</q> set of operations</li>
						<li>many Web-centric technologies try to build on the Web's REST model of interaction</li>
					</ul>
					<li>AtomPub builds on Atom and adds a REST-based protocol on top of it</li>
					<ul>
						<li><http>POST</http> for creating new entries (sending the request to the collection)</li>
						<li><http>PUT</http> for updating existing entries (overwriting the existing entry)</li>
						<li><http>DELETE</http> for deleting entries from a collection</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Collections, Members, Entries, Media</title>
				<ul>
					<li>AtomPub's top-level concept is a <em>collection</em></li>
					<ul>
						<li>collections are used for managing and organizing members</li>
						<li>Atom feed documents are the representation of collections</li>
					</ul>
					<li>Members of a collection can be <em>entry</em> and <em>media</em> resources</li>
					<ul>
						<li>entry resources represent metadata and are represented as Atom entries</li>
						<li>media resources can have any media type and are the data described by entries</li>
						<li>a <em>media link entry</em> is an entry associated with a member</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Protocol Summary</title>
					<table border="1" cellpadding="20" style="width : 90% ; margin : 2% ; ">
						<thead>
							<tr valign="top">
								<th>Resource</th>
								<th>HTTP Method</th>
								<th>Representation</th>
								<th>Description</th>
							</tr>
						</thead>
						<tbody>
							<tr valign="top">
								<td>Introspection</td>
								<td>
									<http>GET</http>
								</td>
								<td><link href="atom-service-documents">Atom Service Document</link></td>
								<td>Enumerates a set of collections and lists their URIs and other information about the collections</td>
							</tr>
							<tr valign="top">
								<td>Collection</td>
								<td>
									<http>GET</http>
								</td>
								<td>Atom Feed</td>
								<td>A list of member of the collection (this may be a subset of all entries in the collection)</td>
							</tr>
							<tr valign="top">
								<td>Collection</td>
								<td>
									<http>POST</http>
								</td>
								<td>Atom Entry</td>
								<td>Create a new entry in the collection</td>
							</tr>
							<tr valign="top">
								<td>Member</td>
								<td>
									<http>GET</http>
								</td>
								<td>Atom Entry</td>
								<td>Get the Atom Entry</td>
							</tr>
							<tr valign="top">
								<td>Member</td>
								<td>
									<http>PUT</http>
								</td>
								<td>Atom Entry</td>
								<td>Update the Atom Entry</td>
							</tr>
							<tr valign="top">
								<td>Member</td>
								<td>
									<http>DELETE</http>
								</td>
								<td>n/a</td>
								<td>Delete the Atom Entry from the collection</td>
							</tr>
						</tbody>
					</table>
			</slide>
			<slide id="atom-service-documents">
				<title>Service Documents</title>
				<blockquote>Service Documents represent server-defined groups of Collections, and are used to initialize the process of creating and editing resources.</blockquote>
				<ul>
					<li>The <q>real</q> top-level construct of AtomPub is the <em>workspace</em></li>
					<ul>
						<li>collections on a server are organized into different workspaces</li>
						<li>workspaces have no AtomPub semantics and no operations can be performed on them</li>
					</ul>
					<li>Service documents list constraints on the members of collections</li>
					<ul>
						<li><atom>accept</atom> specifies a comma-separated list of media ranges (with <code>entry</code> as special value)</li>
						<li><atom>categories</atom> defines the list of categories that can be applied to members (can be <code>fixed</code>)</li>
						<li>APP servers are likely to reject operations not satisfying these constraints</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Service Document Example</title>
				<listing src="atom-service.xml"/>
			</slide>
			<slide id="atom-category-documents">
				<title>Category Documents</title>
				<ul>
					<li>Categories are important for creating and reading entries</li>
					<ul>
						<li>they may contain metadata using any classification scheme</li>
					</ul>
					<li><link href="atom-service-documents"/> contain a list of allowed categories</li>
					<li>APP defines a document format for standalone category documents</li>
					<ul>
						<li>a useful interface between APP systems and other systems using classification schemes</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Category Document Example</title>
				<listing src="atom-category.xml"/>
			</slide>
		</part>
        <part>
			<title>Conclusions</title>
			<slide>
				<title>Semantic Web Light</title>
				<ul>
					<li>Syndication creates representations for universal concepts</li>
					<li>Atom adds some concepts to RSS's model</li>
					<li>Syndication revolves around the idea of interacting with items</li>
					<li>Atom-based interaction is one way of implementing REST</li>
					<li>For more semantics, Atom is only the foundation</li>
				</ul>
			</slide>
        </part>
    </presentation>
    <presentation id="semweb">
        <title>Semantic Web</title>
        <date>2007-11-01</date>
        <toc class="resources"><a href="http://microformats.org/" title="microformats.org">Microformats</a>&#160;· <a href="http://www.w3.org/TR/xhtml-rdfa-primer/" title="RDFa Primer 1.0">RDFa</a>&#160;· <a href="http://www.w3.org/2001/sw/SW-FAQ" title="W3C Semantic Web FAQ">FAQ</a>&#160;· <a href="http://www.w3.org/TR/rdf-primer/" title="W3C RDF Primer">RDF</a>&#160;· <a href="http://www.w3.org/TR/owl-features/" title="W3C OWL Overview">OWL</a></toc>
        <toc class="abstract">HTML pages are for human users and describe a resource in very general terms (headings, lists, tables, …). For machine-based interaction, it is often necessary to have more information about the application concepts. XML is a popular language for representing application structures, but is targeted at machine-based processing alone. <em>Microformats</em> and more formal approaches such as the <em>Resource Description Format (RDF)</em>, <em>RDF in Attributes (RDFa)</em>, and <em>Web Ontology Language (OWL)</em> often are used to describe Web content semantically.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<slide>
			<title>HTML vs. XML</title>
			<ul>
				<li>HTML describes structures in a very general way</li>
				<ul>
					<li>HTML elements describe logical page structures such as headings, lists, tables, …</li>
					<li>useful for dynamic and adaptive page rendering, but not for understanding contents</li>
				</ul>
				<li>Good HTML may have more information available</li>
				<ul>
					<li>classes in HTML elements may represent underlying concepts (CSS may use this)</li>
					<li><link href="html-containers">HTML containers</link> may represent aggregation of some basic information items</li>
				</ul>
				<li>Very good HTML</li>
				<ul>
					<li>some guidelines/rules/methods for <em>understanding</em> class names</li>
					<li>some model for the underlying schema (what may appear in which combination)</li>
				</ul>
				<li>Excellent HTML is dynamically generated from XML</li>
				<ul>
					<li>the model is exposed as structured XML data that is available to the client</li>
					<li>there is a stylesheet for producing the HTML version of the XML</li>
					<li>but even XML does not provide semantics (it is just a structured syntax)</li>
				</ul>
			</ul>
		</slide>
		<slide>
			<title>Plain HTML</title>
			<listing src="systemsix-plain.html"/>
		</slide>
		<slide>
			<title>Good HTML</title>
			<listing src="systemsix-good.html"/>
		</slide>
		<slide>
			<title>Excellent HTML</title>
			<listing src="systemsix.xml"/>
		</slide>
		<slide>
			<title>XML → HTML Stylesheet</title>
			<listing src="bike2html.xsl"/>
		</slide>
		<slide>
			<title>Graceful Degradation</title>
			<ul>
				<li>XML was designed as a language for Web content</li>
				<ul>
					<li>the idea was that XML documents would be delivered to the browser</li>
					<li>stylesheets (CSS/XSL) would take care of the client-side rendering</li>
				</ul>
				<li><link href="css">CSS</link> is good at supporting graceful degradation</li>
				<ul>
					<li>viewing an HTML page with CSS turned off most of the time works fine</li>
				</ul>
				<li>XSL is not good at supporting graceful degradation</li>
				<ul>
					<li>the browser just displays the raw XML when XSL is not supported</li>
				</ul>
				<li>Serving XML on the Web is not a good idea</li>
				<ul>
					<li>in closed scenarios (intranet apps) this might be a viable solution</li>
					<li>in open scenarios, HTML should be served as the default representation</li>
					<li>alternate versions can be provided by supporting <link href="http-content-negotiation"/></li>
				</ul>
			</ul>
		</slide>
		<slide>
			<title>Excellent HTML</title>
			<listing src="systemsix-excellent.html"/>
		</slide>
		<slide>
			<title>From Information, Knowledge</title>
			<ul>
				<li>XML is often said to be <q>self-describing</q></li>
				<ul>
					<li>many people think this is the same as <q>self-explanatory</q></li>
					<li>the catch is what exactly it is you refer to by <q>describing</q></li>
				</ul>
				<li>Database data cannot live without a database</li>
				<ul>
					<li>database data is simply content, the structure is provided by a DBMS</li>
					<li>XML documents have their structure encoded within them</li>
					<li>compared to database data, XML in fact is <q>self-describing</q></li>
				</ul>
				<li>What is the gap between <q>self-describing</q> and <q>self-explanatory</q>?</li>
				<ul>
					<li>it is impossible to find out how the document could be modified</li>
					<li>there are no semantics associated with neither structure nor content</li>
					<li>so <q>self-describing</q> means, you can guess a lot, but you maybe wrong</li>
				</ul>
			</ul>
		</slide>
		<slide>
			<title>The Semantic Web Hype</title>
			<blockquote>1965, H. A. Simon: <q href="http://en.wikipedia.org/wiki/Artificial_intelligence#_note-11">machines will be capable, within twenty years, of doing any work a man can do</q><br />1967, Marvin Minsky: <q href="http://en.wikipedia.org/wiki/Artificial_intelligence#_note-12">Within a generation [ … ] the problem of creating <q>artificial intelligence</q> will substantially be solved.</q></blockquote>
			<ul>
				<li>How to get past the limitations of HTML?</li>
				<ul>
					<li>a machine-friendly Web must make Web resources machine-processable</li>
					<li>XML solved the problem on the syntax level</li>
					<li>how could the problem be solved on the level of semantics?</li>
				</ul>
				<li>As in the 1970's, <em>description logic</em> was declared as being the solution</li>
				<ul>
					<li>there was a need for the Web to move towards semantics</li>
					<li>there was a community of AI researchers with a long history</li>
					<li>the <em>Semantic Web</em> was born and is currently repeating AI history</li>
				</ul>
			</ul>
		</slide>
		<slide>
			<title>Semantic Web Layers</title>
			<img style="width : 90% ; margin : 2% ; " src="semantic-web-layers.png" href="http://www.w3.org/2001/12/semweb-fin/w3csw"/>
		</slide>
		<part id="microformats">
			<title>Microformats</title>
			<slide>
				<title>Islands of Semantics</title>
				<ul>
					<li>Microformats solve very specific problems in a very specific way</li>
					<ul>
						<li>encoding address information on a Web page</li>
						<li>encoding a location of something represented by a Web resource</li>
					</ul>
					<li>Microformats can be compared to <q>tagging</q></li>
					<ul>
						<li>a very simple mechanism with a minimal barrier-to-entry</li>
						<li>little flexibility in adapting the mechanism to slightly other uses</li>
						<li>often underspecified and interpretation implementation-dependent</li>
						<li>no unified rules across different platforms which makes processing hard</li>
						<li>nice and easy to start with, but questionable for robust long-term solutions</li>
					</ul>
					<li>Currently there are about 10 reasonably popular microformats</li>
					<ul>
						<li><a href="http://microformats.org/wiki/Main_Page">calendar entries, addresses, licenses, outlines, geolocation, resumes, social networking, …</a></li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Microformat Syntax</title>
				<ul>
					<li>HTML has some underspecified and underused elements</li>
					<ul>
						<li><htmel>dfn</htmel>, <htmel>code</htmel>, <htmel>samp</htmel>, <htmel>kbd</htmel>, <htmel>var</htmel>, <htmel>cite</htmel>, <htmel>abbr</htmel>, <htmel>acronym</htmel></li>
						<li>they can be reused and augmented with additional information</li>
					</ul>
					<li>HTML allows non-HTML content in HTML pages</li>
					<ul>
						<li>unknown elements and attributes must be ignored</li>
					</ul>
					<li>HTML allows <html>class</html> attributes to carry semantics</li>
					<ul>
						<li>XHTML 2 attempts to move this functionality to a <a href="http://www.w3.org/TR/xhtml-role/"><html>role</html> attribute</a></li>
					</ul>
					<li>HTML has a <htmlel>head</htmlel> which contains page metadata</li>
					<ul>
						<li>for example, the <htmel>link</htmel> element specifies connections to other resources</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Magic Names</title>
				<ul>
					<li>A syntax defines where and how to embed information</li>
					<ul>
						<li>what is embedded and how well is it defined semantically?</li>
						<li>is there an underlying model for specifying dependencies?</li>
						<li>how many assumptions does it take to implement a microformat?</li>
					</ul>
					<li>Names are never self-explanatory, they always represent concepts</li>
					<ul>
						<li>nothing can remove the burden of defining a conceptual model</li>
						<li>if this is not done, models evolve and there will be many more than one</li>
					</ul>
					<li><q>Microformats</q> and <q>tagging</q> share the same folklore</li>
					<ul>
						<li>define simple things and good things will happen</li>
						<li>this works by supporting a quickly growing ecosystem of diverging semantics</li>
						<li>semantics are most useful when they are well-defined</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Microformats on the Web</title>
				<ul>
					<li>Easy to embed for generated content</li>
					<ul>
						<li>some of the very basic formats may even appear in browsers one day</li>
						<li>combining well-designed URIs with document relationships is better than every site map</li>
					</ul>
					<li>Hard to rely on for applications that need dependable semantics</li>
					<ul>
						<li>useful as a hint and as a starting point</li>
						<li>for complex information management tasks microformats are not a good idea</li>
					</ul>
					<li>Use as foundation for representing common concepts</li>
					<ul>
						<li>when formatting addresses, use <html href="http://microformats.org/wiki/adr">adr</html> class names</li>
						<li>for structured documents use <html href="http://microformats.org/wiki/xoxo">XOXO</html> (<a href="">JavaScript support is available</a>)</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part id="rdf">
			<title short="RDF">Resource Description Framework (RDF)</title>
			<slide>
				<title>Describing Resources</title>
				<ul>
					<li>RDF describes everything in <em>triples</em></li>
					<ul>
						<li>making a statement about a <em>resource</em> (identified by a <link href="uri">URI</link></li>
						<li>describing a certain <em>property</em> of the resource</li>
						<li>specifying a <em>value</em> for that property</li>
					</ul>
				</ul>
				<pre href="http://www.w3.org/TR/REC-rdf-syntax/#intro"><![CDATA[<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:contact="http://www.w3.org/2000/10/swap/pim/contact#">
  <contact:Person rdf:about="http://www.w3.org/People/EM/contact#me">
    <contact:fullName>Eric Miller</contact:fullName>
    <contact:mailbox rdf:resource="mailto:em@w3.org"/>
    <contact:personalTitle>Dr.</contact:personalTitle> 
  </contact:Person>
</rdf:RDF>]]></pre>
			</slide>
			<slide>
				<title>RDF Graphs</title>
				<img src="rdf-graph.png" style="height : 75% ; margin : 2% ; " href="http://www.w3.org/TR/REC-rdf-syntax/#intro"/>
			</slide>
			<slide>
				<title>RDF is Simple and Complex</title>
				<ul>
					<li><a href="http://www.w3.org/TR/rdf-concepts/">RDF's abstract model</a> is the idea of descriptive triples</li>
					<ul>
						<li>the actual RDF model is rooted in <em>description logic</em></li>
						<li>RDF itself can only describe individuals (something identified by URI)</li>
					</ul>
					<li><a href="http://www.w3.org/TR/rdf-syntax-grammar/">RDF/XML</a> is an XML syntax for encoding triples</li>
					<ul>
						<li>the syntax allows a variety of ways to represent the same RDF statements</li>
						<li>processing RDF/XML with XML tools is likely to fail</li>
						<li>use RDF parsers to parse all variations of RDF/XML into an abstract RDF graph</li>
					</ul>
					<li><a href="http://www.w3.org/TR/rdf-schema/">RDF Schema</a> supports the creation of <em>RDF vocabularies</em></li>
					<ul>
						<li>describe the <em>classes of things</em> that can be used in statements</li>
						<li>describe the <em>properties</em> which can be used for each of these classes</li>
						<li>describe the <em>allowed</em> values for the supported properties</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>RDF Schema Graph</title>
				<img src="rdfs-graph.png" style="height : 75% ; margin : 2% ; " href="http://www.w3.org/TR/REC-rdf-syntax/#schemaclasses"/>
			</slide>
			<slide id="rdfa">
				<title short="RDFa">RDF in Attributes (RDFa)</title>
				<ul>
					<li>Microformats can use any kind of markup design</li>
					<ul>
						<li>this makes it hard to detect microformats when processing a Web page</li>
						<li>combining microformats can become complicated and ill-designed</li>
					</ul>
					<li>RDFa defines only a syntax for embedding metadata into XHTML</li>
					<ul>
						<li>the vocabulary must be described by some RDF schema language</li>
					</ul>
				</ul>
				<pre><![CDATA[<p>This document is licensed under a <a xmlns:cc="http://creativecommons.org/licenses/" rel="cc:license" href="http://creativecommons.org/licenses/by/nc-nd/3.0/">Creative Commons License</a>.</p>]]></pre>
				<ul>
					<li>RDFa uses and extends HTML for embedding RDF</li>
					<ul>
						<li>it uses HTML's <html>rel</html>, <html>rev</html>, <html>href</html>, and <html>src</html> attributes</li>
						<li>it defines a number of <a href="http://www.w3.org/TR/rdfa-syntax/#s_metaAttributes">new attributes for HTML elements</a></li>
						<li>it defines a <a href="http://www.w3.org/TR/rdfa-syntax/#s_model">processing model</a> for deriving RDF triples from these attributes</li>
					</ul>
				</ul>
			</slide>
		</part>
		<part id="semweb-advanced">
			<title>More Languages</title>
			<slide id="sparql">
				<title>SPARQL</title>
				<ul>
					<li>RDF graphs can be large and hard to handle</li>
					<ul>
						<li>querying RDF graphs using XML technologies is hard and slow</li>
						<li>special data structures need special query languages</li>
						<li>SPARQL is a query language for querying RDF graphs</li>
					</ul>
					<li>Using RDF without using SPARQL does not make a lot of sense</li>
					<ul>
						<li>if the data is simple and restricted, why use RDF?</li>
						<li>processing unrestricted RDF without a special language is very hard</li>
					</ul>
					<li>Semantic Web search engines can harvest the Web for RDF</li>
					<ul>
						<li>the result is a huge graph of RDF describing all semantic Web resources</li>
						<li>querying into this graph retrieves all formalized semantics on the Web</li>
					</ul>
				</ul>
			</slide>
			<slide id="owl">
				<title short="OWL">Web Ontology Language (OWL)</title>
				<ul>
					<li>RDF and RDF Schema are rather basic languages</li>
					<li>OWL adds more sophisticated features to RDF Schema</li>
					<ul>
						<li>constructions of classes using existing ones</li>
						<li>characterize relationships (e.g., whether they are transitive, symmetric, functional, etc.)</li>
					</ul>
					<li>Formal semantics are hard to write and compute</li>
					<ul>
						<li>no property expressions or datatypes in RDF Schemas</li>
						<li>not all set operators, restricted cardinality in <em>OWL Lite</em></li>
						<li>some restrictions, but a computational guarantee in <em>OWL DL</em></li>
						<li>full expressive power in <em>OWL Full</em> (but no computational guarantee)</li>
					</ul>
				</ul>
			</slide>
		</part>
        <part>
			<title>Conclusions</title>
			<slide>
				<title>Some Questions</title>
				<ul>
					<li>Is the world something that can be objectively formalized and described?</li>
					<li>If the conceptualization of the world changes, what about the ontology?</li>
					<li>How can ontology users understand a large ontology?</li>
					<li>Should users trust ontologies which are based on strict categorization?</li>
					<li>How much responsibility should we delegate to formalisms?</li>
					<li>Can <a href="http://video.google.com/videoplay?docid=-7704388615049492068">computer formalizations fully capture semantics</a>?</li>
				</ul>
			</slide>
			<slide>
				<title>Semantics are Important and Hard</title>
				<ul>
					<li>Semantics must be captured somewhere</li>
					<li>Most semantic definitions are using prose and some formalism</li>
					<li>Completely formal semantics are hard to define and hard to use</li>
					<li>Semantic Web technologies may share the fate of AI</li>
				</ul>
			</slide>
        </part>
    </presentation>
    <presentation id="variants">
        <title>Implementation Variants</title>
        <date>2007-11-06</date>
        <toc class="abstract">Today's landscape of Internet and Web technologies offers a sometimes confusingly wide array of implementation choices. Given some application idea, implementation can be done using basic Web technologies, newer <em>Web 2.0</em> technologies, it can use browser-embedded functionality such as <em>Flash</em>, <em>Java Applets</em>, <em>ActiveX</em>, <em>Silverlight</em>, or <em>Google Gears</em>, or it can be built with Web-oriented application development platforms such as <em>Adobe Integrated Runtime (AIR)</em> or <em>JavaFX</em>.</toc>
		<slide>
			<title>Abstract</title>		
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
        <part id="least-power">
			<title>The Principle of Least Power</title>
			<slide>
				<title>Simpler is Better</title>
				<ul>
					<li>Choose the simplest possible language to solve a problem</li>
					<li>Languages must be chosen on different levels</li>					
					<ul>
						<li>data model (informal, ER, UML, …)</li>
						<li>data semantics (informal, microformats, RDF, OWL, …)</li>
						<li>data representation (text, HTML, XML, …)</li>
						<li>data storage (file system, RDBMS, XDBMS, …)</li>
						<li>data retrieval (SQL, SQL/XML, XQuery, …)</li>
						<li>programming language (PHP, Ruby, Python, Java, …)</li>
						<li>programming framework (Rails, J2EE, …)</li>
					</ul>
					<li>Decisions ideally should be future-proof</li>
					<ul>
						<li>Web apps often evolve in unpredictable and surprising ways</li>
						<li>simpler languages make it easier to quickly adapt</li>
						<li>sometimes adaptations may require switching languages</li>
					</ul>
				</ul>
			</slide>
			<slide>
				<title>Iterative Development</title>
				<ul>
					<li>Models are important and useful</li>
					<ul>
						<li>thinking about the problem space is essential</li>
						<li>being able to conceptualize the problem space is important</li>
					</ul>
					<li>Heavyweight models make it hard to change the model</li>
					<ul>
						<li>changing the model is an expensive undertaking</li>
						<li>everything connects to the model and must be changed as well</li>
					</ul>
					<li>Lightweight models make it risky to change the model</li>
					<ul>
						<li>the model can change easily without everybody noticing</li>
						<li>components may break or misbehave because of a new model</li>
						<li>well-designed components should ignore model extensions</li>
					</ul>
				</ul>
			</slide>
        </part>
        <part id="app-architecture">
			<title>Application Architecture</title>
			<slide>
				<title>Resources, REST, UI</title>
				<img style="width : 88% ; margin : 4% ; " src="web-app-tiers.png" title="Web Application Tiers"/>
			</slide>
			<slide>
				<title>Multiple UIs</title>
				<img style="width : 88% ; margin : 4% ; " src="web-app-multiple-ui.png" title="Web Application with Multiple UIs"/>
			</slide>
			<slide>
				<title>Mash-Ups</title>
				<img style="width : 88% ; margin : 4% ; " src="web-app-mashup.png" title="Mash-Up"/>
			</slide>
			<slide>
				<title>Mash-Apps</title>
				<img style="width : 88% ; margin : 4% ; " src="web-app-mashapp.png" title="Mash-App"/>
			</slide>
        </part>
        <part id="wb-app">
			<title>Web-Based Application</title>
			<slide>
				<title>Shipping Data vs. Shipping Code</title>
				<ul>
					<li>Applications should ship data, not code</li>
					<ul>
						<li>REST-based back-ends can support any kind of interface</li>
						<li>shipping code is very client-specific and should be avoided</li>
					</ul>
					<li>Applications should focus on the service perspective</li>
					<ul>
						<li>how to deliver a service that can be easily used by others</li>
						<li>how to describe the service's data model for potential users</li>
						<li>how to control access and authenticate service users</li>
					</ul>
					<li>If possible, other services should be integrated</li>
					<ul>
						<li>if you need authentication, why not use <a href="http://openid.net/">OpenID</a>?</li>
						<li>if you need social networking, why not use <a href="http://code.google.com/apis/opensocial/">OpenSocial</a>?</li>
						<li>if you need location, why not use <a href="http://fireeagle.research.yahoo.com/">Fireeagle</a>?</li>
					</ul>
				</ul>
			</slide>
        </part>
        <part id="ria">
			<title>Rich Internet Application (RIA)</title>
			<slide>
				<title>Shipping Code vs. Shipping Data</title>
				<ul>
					<li><em>Rich Internet Applications</em> are based on the idea of a smarter client</li>
					<ul>
						<li>Ajax applications ship JavaScript code for modern browsers</li>
						<li>Flash applications ship ActionScript code for flash players</li>
						<li>ActiveX applications ship Windows components for IE</li>
					</ul>
					<li>RIAs should be built on top of a RESTful service</li>
					<ul>
						<li>standard services will provide XML-based interactions</li>
						<li>Ajax-specific services may provide JSON representations</li>
					</ul>
					<li>Service and RIA should be completely separated</li>
					<ul>
						<li>if required, the service can be provided as an API</li>
						<li>if required, alternative UIs can be implemented</li>
					</ul>
				</ul>
			</slide>
        </part>
        <part>
			<title>Conclusions</title>
			<slide>
				<title>Divide and Conquer</title>
				<ul>
					<li>Divide Web Apps into REST and UI</li>
					<li>Choose a project to do one or both</li>
					<li>Come up with a <q>project plan</q> for implementing the app</li>
					<li>Choose an app that you care about</li>
					<ul>
						<li>something you would like to see as a Web app</li>
						<li>something you want to do for your final project</li>
						<li>something for the <a href="../services-spring08/">services</a> or <a href="../publishing-spring08/">publishing</a> course</li>
					</ul>
				</ul>
			</slide>
        </part>
    </presentation>
    <presentation id="swot">
        <title>SWOT Analysis</title>
        <date>2007-11-08</date>
        <toc class="abstract">Starting from a desired objective (such as the successful implementation of a well-designed Web app), it can be very informative to assess factors influencing the pursuit of this objective. One way to do it is the analysis of the <em>Strengths, Weaknesses, Opportunities, and Threats (SWOT)</em> of implementation variants, which supports a more structured way of comparing variants, and can be a starting point for choosing the <q>best</q> one.</toc>
		<slide>
			<title>Abstract</title>
			<p class="abstract"><toc class="abstract"/></p>
		</slide>
		<slide>
			<title>Structured Analysis</title>
			<ul>
				<li>Web app planning is a technical task</li>
				<li>Technical problems can be solved in a variety of ways</li>
				<li>Comparing different solutions can be complicated</li>
				<ul>
					<li>even if there is only one solution, understanding it can be hard</li>
				</ul>
				<li>How to describe an objective in a structured way</li>
				<li>How to describe proposals in comparable ways</li>
				<li>How to identify important project issues</li>
			</ul>
		</slide>
		<slide>
			<title>SWOT Matrix</title>
			<img style="height : 75% ; margin : 2% ; " src="swot.png" href="http://en.wikipedia.org/wiki/SWOT_analysis"/>
		</slide>
		<slide>
			<title>Decision-Making and Planning</title>
			<ul>
				<li>SWOT describes an objective in different perspectives</li>
				<li>Strategic decisions can be based on these perspectives</li>
				<li>Additionally, the analysis can be used as a starting point</li>
				<ul>
					<li>how can we use <link href="swot-strengths"/>?</li>
					<li>how can we stop <link href="swot-weaknesses"/>?</li>
					<li>how can we exploit <link href="swot-opportunities"/>?</li>
					<li>how can we defend <link href="swot-threats"/>?</li>
				</ul>
				<li>Given a variety of alternative objectives</li>
				<ol>
					<li>analyze each of them according to their SWOT matrix</li>
					<li>select the <q>best</q> one according to some interpretation</li>
					<li>use the best one's matrix to create a project plan</li>
					<li>SWOT can be <q>nested</q> and used to plan sub-projects</li>
				</ol>
			</ul>
		</slide>
		<slide>
			<title>Enhanced SWOT</title>
			<img style="width : 90% ; margin : 2% ; " src="swot-enhanced.png" href="http://www.jiscinfonet.ac.uk/InfoKits/project-management/enh-swot"/>
		</slide>
        <part id="swot-strengths">
			<title>Strengths</title>
			<slide>
				<title>Helpful and Internal</title>
				<ul>
					<li>Existing resources that can be used</li>
					<li>Experts in certain fields</li>
					<li>Creative capabilities to create innovative solutions</li>
					<li>Experience in similar projects</li>
					<li>Alignment with long-term strategy</li>
					<li>Clearly identified problem, solutions, and stakeholders</li>
				</ul>
			</slide>
			<slide>
				<title>Newspaper Front Pages</title>
				<ul>
					<li>Web app design skills (versatile back-end)</li>
					<li>UI and UX skills (multiple interfaces)</li>
					<li>NLP skills (extracting additional metadata)</li>
					<li>Cooperation with the <a href="http://www.archive.org/">Internet archive</a> (image storage)</li>
				</ul>
			</slide>
        </part>
        <part id="swot-weaknesses">
			<title>Weaknesses</title>
			<slide>
				<title>Harmful and Internal</title>
				<ul>
					<li>Lack of resources (short-term or long-term)</li>
					<li>No previous experience in the area</li>
					<li>Not well-aligned with the long-term strategy</li>
					<li>Lack of stakeholders (who are interested and responsible)</li>
					<li>Competing with similar in-house project</li>
					<li>Association with failed previous projects</li>
				</ul>
			</slide>
			<slide>
				<title>Newspaper Front Pages</title>
				<ul>
					<li>High network and server load can become problematic</li>
					<li>App monitoring and management can become an issue</li>
				</ul>
			</slide>
        </part>
        <part id="swot-opportunities">
			<title>Opportunities</title>
			<slide>
				<title>Helpful and External</title>
				<ul>
					<li>Differentiating factor with competitors</li>
					<li>General move of the markets in this direction</li>
					<li>Easy integration with related products/solutions</li>
					<li>Regarded as <q>must have</q> on high-level check lists</li>
				</ul>
			</slide>
			<slide>
				<title>Newspaper Front Pages</title>
				<ul>
					<li>Nice mix of information and <q>art</q> (mix with other ISchool apps)</li>
					<li>Attract students to projects that build stuff</li>
					<li>Start building an infrastructure of services</li>
				</ul>
			</slide>
        </part>
        <part id="swot-threats">
			<title>Threats</title>
			<slide>
				<title>Harmful and External</title>
				<ul>
					<li>Market changes (economic valuation)</li>
					<li>Copyright and licensing issues</li>
					<li>Dependencies on other services/companies</li>
					<li>Technological changes</li>
					<li>Changes in the landscape (devices, customers, players)</li>
				</ul>
			</slide>
			<slide>
				<title>Newspaper Front Pages</title>
				<ul>
					<li>No official feed of images (screen scraping)</li>
					<li>Licensing issues with the individual pages</li>
					<li>No back-up channel when feed fails/stops</li>
				</ul>
			</slide>
        </part>
        <part>
			<title>Conclusions</title>
			<slide>
				<title>SWOT Problems</title>
				<ul>
					<li>No focus on long-term strategic goals</li>
					<li>Little focus on ROI (life <q>after reaching the objective</q>)</li>
					<li>Comparing SWOT analyses can be hard (no metrics)</li>
				</ul>
			</slide>
			<slide>
				<title>SWOT Essentials</title>
				<ul>
					<li>SWOT always needs a well-defined objective</li>
					<li>SWOT analyses are highly subjective</li>
					<li>Structuring tools can be used as personal tools</li>
				</ul>
			</slide>
        </part>
    </presentation>
 </xslidy>