Abstract

The Hypertext Markup Language (HTML) and its ability to present forms has driven the first wave of Web-based services, which mostly provided Web forms for submitting data to some process being driven by such a Web-based front-end. The Extensible Markup Language (XML) then introduced the ability to represent application-defined data structures. XML is the most important foundation of almost all technologies in the Web and Web Service technology areas.

Services need Interfaces

• Web-based services are accessed using Web technologies
  • information transfer uses HTTP
  • human-oriented interfaces use HTML
  • machine-oriented interfaces use XML
• Service design before interface design
  • service design should concentrate on the task, not on the consumer
  • a well-designed interface can be adapted to different service interfaces
  • document-style interfaces are more robust
  • API-style interfaces are harder to adapt and reuse

The Web's Document Format

• Web documents use HTML
  • all other formats have usability or accessibility issues
  • Web browsers are rendering engines for HTML retrieved over HTTP
• Web documents are hypermedia documents
  • hypermedia enables the seamless navigation between documents of different types
  • using HTML Forms, documents can accept data input (which is sent via HTTP)
• The Web evolved to be the interface for many applications
  • form-based applications were the beginning (search terms)
  • scripted forms improve the interface, but are not very portable
  • AJAX moves the Web to better interfaces (Software as a Service)
  • XForms are the next major step in Web-based interfaces

Document Layout

• HTML describes layout structures
  • textual structures (paragraphs and inline elements)
  • list structures (different types of enumerations)
  • tabular structures (often used for page layout)
• HTML also supports formatting functionality (e.g., including images)
• CSS is used to change formatting parameters
  • CSS was designed to keep formatting out of HTML
  • HTML can focus on structure, CSS defines the layout (CSS is very powerful)
  • CSS layouts can be reused for a large number of pages

Hypermedia Features

• Apart from formatting, HTML also defines document semantics
  • img instructs the browser to embed an image
  • object embeds any kind of object (if supported by the browser)
  • input displays an input field which is part of a form
• HTML's hypermedia capabilities are very basic
  • links are always one-to-one
  • links are untyped
  • links are always embedded
  • there is no transclusion of textual content

HTTP Web Services

• Services can be provided through URI/HTTP
  • URI-based services need input as a query string
  • the question is how the user gets information into the URI
• HTML forms provide an interface for assembling query strings
  • users fill out a form providing several fields
  • the browser submits the entered information by HTTP to a URI
  • the result of the request is displayed to the user
• HTTP has to different methods for submitting data
  • GET encodes the data as a URI query string
  • POST encodes the data as HTTP request entity

Forms Mechanics

• HTML forms are normal Web pages (using form elements)
• The process receiving the form data produces a result page

Forms Markup

• All form elements must be inside a form element
  • specifies the URI for submitting the form values (action="URI")
  • specifies the method for submitting the form values (method="GET|POST")
  • for POST forms, the encoding may be selected
• form contains regular HTML markup and form elements
  • the regular HTML markup creates the form's layout (table, list, texts)
  • the form elements create the controls for acquiring input data
• Each form should have a submit button
  • when pressing this button, the form values are sent to the action URI
  • without such a button, the form values cannot be submitted

Forms Elements (User View)

• HTML provides a small set of form controls
• Sufficient for a many applications

Forms Elements (Source View)

<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>

Forms and GET

• Limited to string-oriented form values
  • but HTML forms also allow file upload (this requires POST)
• All values of all form input fields are collected
  • for text and selection fields, this is one input field
  • for checkboxes and radio buttons, this collects the selected fields
• The browser composes a URI query string
  • the form submission is a set of name/value pairs (names may appear more than once!)
  • using URI query string notation, it is appended to the URI of the form's action
• GET is good!
  • URI-encoded queries can be bookmarked and otherwise reused (e.g., cached)
  • if possible, use GET when implementing a form

HTTP POST

• GET encodes the values in the URI
  • for file uploads, this is not possible
  • HTTP's POST request method can upload data
• POST sends a request containing an entity
  • the HTTP request then looks similar to a response (header fields and entity)
  • the receiving process (the Web server) accepts the POST body
• Entities can use any format (it is specified in a header field)
  • just like e-mails, entities can have multiple parts
  • the parts are separated using the standard MIME mechanism

Forms and POST

• POST is used if the form specifies it
  • it can (but should not) be used for non-file forms
  • it should be used for file upload forms (otherwise, only the name is uploaded)
• File upload forms must specify the appropriate encoding
  • application/x-www-form-urlencoded is the default (values in the entity)
  • multipart/form-data is required for file upload (multipart form data)
• The server side must be prepared to receive POST requests
  • it must parse the entity rather than the URI's query string
  • form values can then be extracted from the entity
  • some environments (e.g., PHP) allow to handle GET/POST transparently

Processing of Form Data

• Form data is always encoded
  • as a query string when using GET
  • in an encoded entity when using POST
  • in a multipart entity when using POST with multipart/form-data
• Parsing the form data should be done by existing software
  • most Web-aware programming environments provide this functionality
  • PHP allows access through different mechanisms

Query Parameter Test:
<?php
import_request_variables("gP", "form_");
echo $form_test;
?> 

Structuring Forms

• HTML forms are very loosely structured
  • form somewhere representing the container
  • inside the form a random collection of HTML and form inputs
• Visually, the structure often is (and should be) easy to see
  • for non-visual access, more structure must be provided
  • accessibility has become a major issue on the Web
• Accessibility has many different facets
  • voice browsers must be able to read aloud Web forms
  • gateways should be able to intelligently re-structure Web forms

Labels

• Label and form control are not connected by HTML

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

• The label element allows to make this connection
  • it connects a form control with the describing label
  • this association is now accessible to clients for processing

<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>

Fieldsets

• Complex forms may need structuring
  • groups of controls for subsets of the collected data
  • this structure should be represented in markup

<fieldset><legend>Billing</legend>billing form controls…</fieldset>
<fieldset><legend>Shipping</legend> shipping form controls … </fieldset>

• Excellent example for HTML's markup design philosophy
  • if a client does not support fieldsets, the elements are ignored
  • the title of the fieldset will be displayed, because it is text

Tabbing in Forms

• Tabbing is a very convenient way of navigating a form
  • after completing one field, users should be taken to the next
  • the order should be defined by the form creator, not by accident
• the tabindex attribute defines the tabbing order
  • it contains a number which is interpreted relative to other numbers
  • all form controls may carry a tabindex attribute
• tabindex 1-9: 1 7 3 6 8 2 1 4 5 9

Disabled and Readonly Controls

• In complex scenarios, certain controls may be disabled or readonly
  • based on a workflow, some controls may not apply in all cases
  • for the sake of a consistent view, they should still be included in the interface
• Disabled controls are not used
  • they cannot be tabbed to and never receive focus
  • their value is not included in the form's submission data
• Readonly controls cannot be changed
  • they can be tabbed to and may receive focus
  • their value may not be changed (important for radio buttons and checkboxes!)
  • their value is included in the form's submission data
• Important: Never trust the Browser!

Disabled and Readonly Controls Display

HTML Forms and XForms

• XForms is the next generation of Web forms
  • XML-oriented data model (XML in, XML out)
  • improved structuring of forms (multi-page forms)
  • decoupled data, logic, and presentation
  • richer set of supported data types

XForms Model

Server-Side XForms

Interactions on the Web

• HTML Web pages are human-readable
• HTML Web forms are human-fillable
• First-generation Web technologies have been designed for humans
• Automation requires more machine-understandable formats
• XML is a good syntax for many of these formats

HTML is for Humans

• HTML is a format for dead ends
  • HTML is good for rendering Web pages
  • HTML is bad for understanding Web pages
  • the browser is a dead end (from a machine's point of view)
• Web growth in the late 90's was enormous
  • everybody was putting information online
  • but this information was inaccessible for machines
• How can this information be made accessible to machines?
  • HTML is not the right format (slightly better than fax machines)
  • there was no other widely accepted format for structured data

A Machine-Friendly Web

• Information should be published in a machine-understandable format
  • HTML is good for rendering Web pages
  • HTML is bad for understanding Web pages
  • understanding is the key term here: application semantics!
• Information should be published in application-specific formats
  • HTML is one application: Rendering documents for humans
  • machines need other structures to process Web content
• 1996: W3C Working Group SGML on the Web
  • HTML is just one document type defined with SGML
  • SGML is a very complex and expensive technology
  • how can SGML be made easily and widely usable?

XML Documents on the Web

• XML's idea was that content should be published as XML
  • stylesheets could then be used to render human-readable views
  • machines could simply use the underlying XML
• There are (almost) no XML documents on the Web
  • stylesheet support depends on browsers (software has a long life!)
  • many content providers do not want to publish machine-readable data
• There are many XML documents behind HTML documents
  • content does not have to be made public in a machine-readable way
  • browser-independent HTML can be produced from XML
  • XML technologies can be leveraged on the server-side

SGML/HTML/XML/XHTML

HTML Form Interfaces

• Simple user interfaces to Web-based services
• Interaction is based on standard Web technologies
• For machine-based interactions, XML is much better

Form Design

• Assignment 2 is about designing a form
  1. understand a very simple data model and think about search capabilities
  2. design an HTML form providing an interface for these capabilities
  3. implement the HTML form
• Assignment 3 will make the form functional
  • Assignment 2 results in a form without function
  • some of the proposals will be implemented as a service
  • when the functions are there, they can be used to make the form functional