• You still have to validate. (Why?)
• Asynchronous requests are still requests.

• How many adversaries?
• How many well-meaning errors?
• You may still save cycles.
• User experience still better.

• XML was intended to be shipped to the client.
• XSLT in the client is a failure.
• It cannot ever work.
• You can't use it even if it works.
• You shouldn't use it even if you can.
• XML was never intended to be shipped to the client and parsed there.
• It belongs on the server.

• Reusability of data.
• Self-determination by authors and publishers.
• Freedom of ontology.
• Ability to deliver on the Web using descriptive markup.

• The slides have changed since the handout was prepared. Current version at http://www.blackmesatech.com/2009/09/workstation if you wish to follow along.

• Internet Explorer
• Mozilla
• Firefox
• Opera
• Safari

<?xml-stylesheet 
  type="text/xsl" 
  href="http://cmsmcq.com/lib/swebtohtml.xsl"
?> 

• document() missing in Opera
• namespace::* missing in Firefox
• unparsed-entity-uri() missing or buggy in some browsers
• xsl:output method="xml" (often used to produce XHTML) displays formatted in Safari and Opera, unformatted in Firefox (and IE?). So grit your teeth and use xsl:output method="html".

1. edit locally
2. display locally
3. upload to server without changing anything
4. display on the Web

• parallel structures
• ghost stylesheets

1. Does same server serve all
   • XML documents
   • XSL and CSS stylesheets
   • DTDs and other ancillary files
2. Do you have r/w access to the server?

• Mirror (the relevant parts) of your server locally, with the same directory structure.
• Use relative references for all stylesheets, DTDs, etc.
• Working locally, relative references point to file-system copies.
• Working on the Web, relative references point to server-side copies.

<!DOCTYPE TEI.2 
  PUBLIC '-//C. M. Sperberg-McQueen//DTD
          TEI Lite 1.0 plus SWeb (XML)//EN'
          '../../../lib/swebxml.dtd' >
<?xml-stylesheet type="text/xsl" 
  href="../../../lib/swebtohtml.xsl"?> 
<TEI.2>
  <!--* ... *-->
</TEI.2>

• e.g. multiple sites involved
• e.g. collaborators don't want to mirror your site

• On client
  • Make a ./lib subdirectory everywhere* you have XML instances.
  • Use a symbolic link to a single master copy.
  • Collaborators can just copy the data.
• In the document
  • Refer to stylesheets and DTD in ./lib subdirectory.
• On the server
  • Redirect all references to .../lib/foo.xsl to standard location.
    • Using HTTP redirect (preferable).
    • Using server-side rewrite or other tricks (if necessary).

<!DOCTYPE TEI.2 
  PUBLIC '-//C. M. Sperberg-McQueen//DTD
          TEI Lite 1.0 plus SWeb (XML)//EN'
          'lib/swebxml.dtd' >
<?xml-stylesheet type="text/xsl" 
  href="lib/swebtohtml.xsl"?> 
<TEI.2>
  <!--* ... *-->
</TEI.2>

• XML
• normal display
• simplified display
• XML in HTML
• two-column formated + source display

• offer choices
• pass parameters to stylesheet
• invoke when choose
• invoke on ancillary documents

• load arbitrary document into DOM
• load arbitrary stylesheet into DOM
• invoke arbitrary stylesheet on arbitrary data
• display result as whole document
• display result as partial document

• DomFromXmluri(uri) → DOM-instance
• DomFromXmlstring(string) → DOM-instance
• DomFromTransformXmlXslt(iDOM,xslDOM) → DOM-instance
• DomFromTransformXmlXsltParams(iDOM,xslDOM,parametres) → DOM-instance

• Poor integration with XML
• Limited features make even common tasks dependent on scripting
• Device dependent, running well only on desktop browsers
• Blending of purpose and presentation
• Limited accessibility features

• model: digital representation of reality
• view: user interface exposing (part or all of) model
• controller: intermediary between model and view

• model: one or more XML documents
• view: XHTML page with XForms widgets, CSS styling, etc.
• controller: binding of widgets to elements and attributes

• In large projects, work is often layered / staged.
• In each layer, focus on one task.
• ... so focus on one operation.
• Full XML editors support many operations.
• So full XML editors are dangerous (as well as hard to learn).
• What we need are safer editors. Lots of them.
• As a consequence, we need quicker ways to develop highly specialized editors.

• Type-awareness
• Auto-calculation
• In-client validation
• Conditional visiblity
• Dynamic labels
• Complex multi-part forms

• text input
• textarea
• invisible-text
• file uploads
• select one from list
• select several from list
• submit

• new output widget
• range
• relevant control
• no hidden widget
• the reset widget intentionally made harder
• richer submit: multiple submission possibilities from same data

• relevance:
  • xf:bind can specify conditional relevance of an item.
  • Irrelevant widgets are not shown.
  • Irrelevant elements, attributes are not submitted.
• switch and case elements:
  • Turns blocks of the view on and off en bloc.
  • Allows user control of navigation in multi-part forms.

• basic datatype validation
• range checking
• in-page calculations
• in-page references to forms data
• nested groups of fields
• repeating groups of fields
• adding or deleting items or groups of items

<h:html xmlns:h="http://www.w3.org/1999/xhtml"
        xmlns:x="http://www.w3.org/2002/xforms" >
 <h:head>
  <h:title>Search form</h:title>
  <x:model>
   <x:submission id="s" method="put"
    action="file:///home/cmsmcq/2003/talks/xforms/output.data.xml" />
  </x:model>
 </h:head>
 <h:body>
  <h:h1>Search form</h:h1>
  <h:p><x:input ref="q"><x:label>Find</x:label></x:input></h:p>
  <h:p><x:submit submission="s"><x:label>Go</x:label></x:submit></h:p>
 </h:body>
</h:html>

• Orbeon Forms
• Chiba

• OpenOffice
• Lotus Forms
• X-Smiles (Helsinki Univ. of Technology) XML browser in Java, runs both stand-alone and embedded; can also run in browser as applet