(4) Keep It Simple (KISS)

• Loose coupling vs. tight coupling
  • fewer requirements for cooperation mean fewer potential sources of problems
  • taking independent developments into consideration (graceful degradation)
• Parsimony may conflict with optimization
  • a fully backlinked Web would be a very different hypermedia system
  • modifying resources would be expensive and require considerable efforts
  • an uncontrolled Web allows failure and innovative development
• Programming Languages vs. Frameworks
  • programming languages are very simple and very powerful
  • frameworks are more complex and have some choices built into them
  • both can be used to build good systems
  • framework applications are more likely to not do really innovative things

(5) Web Design as System Design

There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.

C. A. R. Hoare [http://en.wikipedia.org/wiki/Charles_Antony_Richard_Hoare], The Emperor's Old Clothes, 1980 Turing Award Lecture [http://dret.net/biblio/reference/hoa81]

• Web: URI + HTTP + HTML ( + XML)
• OASIS: Six SOA simplification committees [http://www.infoworld.com/article/07/08/09/sca-oasis_1.html] for about 60 WS-* specs [http://en.wikipedia.org/wiki/List_of_Web_service_specifications]
• The Web is a system (of systems!)
  • (that latter part is often overlooked)

(6) Technology Blinders

• Web architecture is an additional set of constraints
  • it is not a very complicated set of constraints
  • but it still makes life more complicated than in an unconstrained world
  • it may require a major redesign of an application
• Technology providers sometimes ignore Web architecture
  • multimedia presentation concepts are often disconnected from the Web
  • hypermedia researchers often regard the Web as inferior (or not as hypermedia at all)
  • questions of client capabilities are often ignored (or brushed aside using statistics)
• Integration vs. Transport
  • integrating into the Web requires applications to conform to Web architecture
  • sitting on top of the Web just requires to use HTTP for data transfer
  • many Web Technologies are not integrated into the Web
  • many Web Applications are not integrated into the Web

(8) Identification

• Everything should be identified in a uniform way
• Identification and access methods evolve over time
  • sms: and tel: did not exist when the Web was created
• Identification and access support evolve over time
  • tel: now can be supported by an increasing number of clients
• The Web is one huge proof for the power of network effects
  • it also is a lesson for many who did not take it seriously and failed

(9) Interaction

• Many URI schemes are named after protocols
  • http: can be accessed using the Hypertext Transfer Protocol (HTTP)
  • ftp: can be accessed using the File Transfer Protocol (FTP)
  • mailto: sends electronic mail using the Simple Mail Transfer Protocol (SMTP)
• Some URI schemes do not directly specify a protocol
  • mailto: sends electronic mail using the Simple Mail Transfer Protocol (SMTP)
  • mailto: may use any other appropriate technology for sending email
  • instead of using protocols directly, they can be used indirectly through services [http://dret.typepad.com/dretblog/2008/06/web-based-sms.html]
• Some URI schemes have no protocol for dereferencing resources
  • urn: URIs are abstract names from some namespace
  • urn:ietf:rfc:2648 identifies an IETF standard and not some specific copy
  • geo:27.988056,86.925278 [http://maps.google.com/maps?ll=27.988056,86.925278&spn=0.1,0.1&q=27.988056,86.925278+(Mount_Everest)] identifies a physical resource (accessing it is really hard)

(10) Data Formats

• Agreement on the interpretation of resource representations
• HTML was the first standardized data format on the Web
  • CSS and XML have become successful formats as well
• Some data formats are de-facto standards as Web formats
  • GIF and JPEG for images and PNG as the successor of GIF
• Some formats are less integrated but still widely used
  • PDF for paginated documents
• Some formats have become replacements for missing standards
  • Flash for audio and video because no single format was sufficiently successful
• Some formats were intended to become standards but failed
  • SVG for vector graphics
  • SMIL for multimedia presentations

(12) Constraints

• Some things on the Web can be inconsistent
  • guaranteeing consistency by design can lead to tight coupling
  • well-defined ways of handling inconsistencies are better scalable
• Some things on the Web are not perfect
  • technologies being used in ways not anticipated (XML, XML Namespaces)
  • company goals vs. the greater good (browser war [http://en.wikipedia.org/wiki/Browser_wars])
• The ideal Web vs. the real Web
  • dealing with a given landscape can introduce additional constraints
  • handling these constraints should not violate the general principles

(13) Good Practices

• Design for openness and extensibility is a key factor
  • design for and support evolution and extension and reuse
  • try to be a good Web citizen by embracing reuse and repurposing
• Design with the Web in mind
  • use Web standards where appropriate (URIs for identification)
  • even intranet applications typically evolve and should be designed for the Web
• Make content visible, accessible, usable, reusable
  • URI design guidelines should be defined and followed
  • think about aggregation and granularity and access to resources
  • use well-defined and well-documented XML for B2B scenarios
  • reuse existing vocabularies or vocabulary parts whenever possible