<?xml version='1.0'?>
<!DOCTYPE slideshow SYSTEM "slide.dtd">
<slideshow>
 
<showtitleslide>
  <title>II. Data and Documents</title>
  <occasion>University of California Extension</occasion>
  <location>Sunnyvale, June 10, 1999</location>
  <speaker>Jon Bosak</speaker>
  <org>Sun Microsystems</org>
</showtitleslide>
 
<slidemodule>
 
  <moduletitleslide>
	 <title>XML Data Scenarios</title>
  </moduletitleslide>
 
  <slide>
	 <head>1: Loosely-coupled data exchange</head>
	 <image src="hosp1.gif">[The hospital problem]</image>
	 <p>Every organization uses a different database schema. The
		interchange problem is combinatorial.</p>
  </slide>

  <slide>
	 <head>The role of a hub format</head>
	 <image src="hosp2.gif">[Hub format for data interchange]</image>
	 <p>Conversion is reduced to one input program and one output
		program for each organization regardless of the number of
		organizations.</p>
  </slide>

  <slide>
	 <head>Other loosely-coupled data scenarios</head>
	 <bulletlist>
		<item>
		  <p>Financial services (banking, securities, insurance)</p>
		</item>
		<item>
		  <p>Government</p>
		</item>
		<item>
		  <p>Legal publishing</p>
		</item>
		<item>
		  <p>Pharmaceuticals (drug approval process)</p>
		</item>
		<item>
		  <p>Collaborative design efforts</p>
		</item>
		<item>
		  <p><emph>Electronic commerce</emph></p>
		</item>
	 </bulletlist>
  </slide>

  <slide>
	 <head>2: Client-side processing</head>
	 <p>Example: semiconductor data</p>
	 <image src="semicond.gif">[Mfr. databases driving client processes]
		</image>
  </slide>

  <slide>
	 <head>This is a widely applicable model!</head>
	 <image src="realtors.gif">[Real estate agents using the same
		architecture]</image>
  </slide>

  <slide>
	 <head>Other client-side processing applications</head>
	 <bulletlist>
		<item>
		  <p>Design applications where the a designer considers various
			 alternatives: electronics, engineering, architecture, etc.</p>
		</item>
		<item>
		  <p>Scheduling applications where a customer explores various
			 possibilities: airlines, trains, buses, and subways; restaurants,
			 movies, plays, and concerts</p>
		</item>
		<item>
		  <p>Commercial applications that allow consumers to explore
			 sales alternatives: real estate, automobiles, appliances, etc.</p>
		</item>
	 </bulletlist>
	 <p>There is an obvious connection with Java here!</p>
  </slide>

  <slide>
	 <head>3: User views of the data</head>
	 <bulletlist>
		<item>
		  <p>Different views of whole documents</p>
		  <bulletlist>
			 <item>
				<p>Novice view vs. expert view</p>
			 </item>
			 <item>
				<p>Outline vs. content</p>
			 </item>
			 <item>
				<p>Generated Tables of Contents</p>
			 </item>
		  </bulletlist>
		</item>
		<item>
		  <p>Different views of document components</p>
		  <bulletlist>
			 <item>
				<p>Bar graph vs. pie chart</p>
			 </item>
			 <item>
				<p>Totals by region vs. totals by business unit</p>
			 </item>
		  </bulletlist>
		</item>
	 </bulletlist>
	 <p><b>Why HTML can't handle multiple views:</b></p>
	 <numberedlist>
		<item>
		  <p>Fixed tag set is not rich enough to support alternative
			 views of the same data</p>
		</item>
		<item>
		  <p>Fixed presentation of each element makes it hard to change
			 the way data is rendered</p>
		</item>
	 </numberedlist>
  </slide>

  <slide>
	 <head>4: Web agents</head>
	 <p>Example: the 500-channel TV guide</p>
	 <image src="tvguide.gif">[The 500-channel TV guide]</image>
	 <p>Once again, a category of applications depends on the ability to
		standardize on a form of data representation for a particular industry
		or problem domain.</p>
  </slide>

  <slide>
	 <head>5: Collection management</head>
	 <p>Collection management is what originally put XML parsers in both
		major Web browsers.</p>
	 <p>RDF is a standardized XML language for representing web objects
		in a <emph>directed labeled graph </emph>(DLG).</p>
	 <bulletlist>
		<item>
		  <p>W3C initiative</p>
		</item>
		<item>
		  <p>Starting to be implemented in Netscape software</p>
		</item>
		<item>
		  <p>Will become increasingly important</p>
		</item>
	 </bulletlist>
  </slide>

</slidemodule>

<slidemodule>
 
  <moduletitleslide>
	 <title>XML Document Exchange</title>
  </moduletitleslide>
 
  <slide>
	 <head>Documents vs. data</head>
	 <p>This is essentially a difference in purpose.</p>
	 <bulletlist>
		<item>
		  <p>Data</p>
		  <bulletlist>
			 <item>
				<p>Order-independent</p>
			 </item>
			 <item>
				<p>Shallow structure</p>
			 </item>
			 <item>
				<p>Low text/tag ratio</p>
			 </item>
		  </bulletlist>
		</item>
		<item>
		  <p>Documents</p>
		  <bulletlist>
			 <item>
				<p>Order-dependent</p>
			 </item>
			 <item>
				<p>Deep structure</p>
			 </item>
			 <item>
				<p>High text/tag ratio: requires mixed content</p>
				<codesample>&lt;foo&gt;This is &lt;emph&gt;mixed&lt;/emph&gt; content.&lt;/foo&gt;</codesample>

			 </item>
		  </bulletlist>
		</item>
	 </bulletlist>
	 <p>Supporting documents is much harder than supporting data. XML is
		becoming ubiquitous because it can serve <emph>both </emph>purposes.
	 </p>
  </slide>

  <slide>
	 <head>A brief history of documents</head>
	 <bulletlist spacing="wide">
		<item>
		  <p><b>4000 BC: </b>inventories</p>
		</item>
		<item>
		  <p><b>3500 BC: </b>signed inventories</p>
		</item>
		<item>
		  <p><b>3000 BC: </b>signed, labeled inventories (contracts,
			 credit and debit ledgers, labor accounting, deeds, etc.)</p>
		</item>
		<item>
		  <p>Every other application of writing comes <emph>later</emph>
		  </p>
		</item>
	 </bulletlist>
	 <p>In the beginning, the typical document was a <emph>business
		</emph>document.</p>
	 <p>Today, the typical document is <emph>still </emph>a business
		document.</p>
  </slide>

  <slide>
	 <head>More recent developments in documents</head>
	 <bulletlist spacing="wide">
		<item>
		  <p><b>Classical era: </b>Spaces between words</p>
		</item>
		<item>
		  <p><b>Medieval era: </b>Codices (i.e., books) instead of
			 scrolls</p>
		  <bulletlist>
			 <item>
				<p>Random access to contents</p>
			 </item>
			 <item>
				<p>Page layout</p>
			 </item>
		  </bulletlist>
		</item>
	 </bulletlist>
  </slide>

  <slide>
	 <head>The eternal document</head>
	 <bulletlist>
		<item>
		  <p>Despite many changes in media, business documents themselves
			 haven't changed fundamentally for centuries</p>
		</item>
		<item>
		  <p>Most other documents haven't changed much, either</p>
		</item>
	 </bulletlist>
	 <p>People just like to do some basic things by exchanging
		documents. <i>They will continue to do so.</i></p>
	 <p>In particular, electronic commerce will be accomplished through
		the exchange of documents, because only a <i>displayed document </i>can
		be a contract.</p>
  </slide>

  <slide>
	 <head>Requirements for documents</head>
	 <numberedlist>
		<item>
		  <p>You have to be able to exchange them.</p>
		  <p>GOT THAT (XML)</p>
		</item>
		<item>
		  <p>You have to be able to display them.</p>
		  <p>YOU ARE HERE (CSS)</p>
		</item>
		<item>
		  <p>You have to be able to format them automatically at a level
			 that will satisfy a graphic designer.</p>
		  <p>THIS COMES NEXT (XSL)</p>
		</item>
		<item>
		  <p>You have to know what they mean.</p>
		  <p>THIS IS THE REALLY HARD PART</p>
		</item>
	 </numberedlist>
  </slide>

  <slide>
	 <head>Basic methods of XML document display</head>
	 <bulletlist>
		<item>
		  <p>Procedural (scripts, programs)</p>
		  <bulletlist>
			 <item>
				<p>Very powerful</p>
			 </item>
			 <item>
				<p>Very difficult to manage on a large scale (e.g.,
				  editing)</p>
			 </item>
		  </bulletlist>
		</item>
		<item>
		  <p>Declarative (stylesheets)</p>
		  <bulletlist>
			 <item>
				<p>More limited (though still very powerful)</p>
			 </item>
			 <item>
				<p>Vastly more manageable and user-friendly</p>
			 </item>
		  </bulletlist>
		</item>
	 </bulletlist>
	 <p>The evolutionary trend in display technology is away from the
		procedural and stream-oriented and toward the declarative and
		object-oriented (example: PostScript vs. PDF)</p>
  </slide>

  <slide>
	 <head>The delusion that print formatting is pass&#233;</head>
	 <bulletlist>
		<item>
		  <p>As displays improve, online formatting will stop being a
			 subset of print formatting</p>
		</item>
		<item>
		  <p>In fact, online formatting will be recognized as a
			 <emph>superset </emph>of print formatting</p>
		  <bulletlist>
			 <item>
				<p>Within the next decade, display quality will come to
				  equal print quality</p>
			 </item>
			 <item>
				<p>Given the capability, online designers will <emph>demand
				  </emph>print layout control for the screen</p>
			 </item>
			 <item>
				<p>This means complete control over formatting and page
				  geometry <emph>even when users change the aspect ratio of the
				  page</emph></p>
			 </item>
			 <item>
				<p>And it adds other new dimensions to traditional print
				  requirements: animation and interactivity</p>
			 </item>
		  </bulletlist>
		</item>
		<item>
		  <p>XSL must provide not only powerful transformational ability
			 but also powerful formatting ability</p>
		</item>
	 </bulletlist>
  </slide>

  <slide>
	 <head>Requirements for XSL</head>
	 <bulletlist>
		<item>
		  <p>Structural transformation to (X)HTML for online display in
			 the short term</p>
		</item>
		<item>
		  <p>Complex layout and typography for print output and online
			 display in the long term</p>
		</item>
	 </bulletlist>
	 <p>Current problem: lots of implementation work happening in XSL
		transformation (XSLT), very little happening in XSL formatting.</p>
	 <bulletlist>
		<item>
		  <p>XML rendering is limited to the CSS level (no knowledge of
			 page or column boundaries, multiple text flows, etc.)</p>
		</item>
		<item>
		  <p>XML is trapped in middleware, and we are <emph>back where we
			 started.</emph></p>
		</item>
	 </bulletlist>
	 <p>Bright spots: Interleaf, FOP (James Tauber)</p>
  </slide>

</slidemodule>

</slideshow>
