Principles re: Resource Representations

Webarch Chapter 3.

Notes:

• Much less cooked, several issues open
• This is what goes in a resource representation.
• Typically accompanied by MIME-packaged metadata, e.g. HTTP headers.

Consensus developed Nov. 18 on the following:

Consider using XML

Pro and contra points, and detailed guidelines for using XML in designs well-presented in an excellent IETF BCP Guidelines for the Use of XML within IETF Protocols, also available in HTML.

URI Schemes

When specifying the use of URIs, designers SHOULD NOT constrain the use of URI schemes.

Use Namespaces

XML-based languages for widespread common use MUST be given an XML namespace name and the elements of the language MUST be placed in that namespace.

Unified formatting semantics

For languages whose contents are intended for visual rendering for presentation to humans, the repertoire of formatting semantics SHOULD be consistent across the universe of W3C recomnmendations.

Web-scale linking

When designing a language that includes linking or hypertext functionality, designers SHOULD design that functionality so it supports Web-wide rather than merely local linking.

Media-type registration

Designers of languages which will be used in resource representations MUST arrange for the registration of an Internet Media Type for that language, and SHOULD consider the recommendations of RFC3203 in carrying out that registration. This registration MUST include a specification of the handling of fragment identifiers for resource representations in the language being designed

Still open:

Separate presentation, interaction, content

Not always achievable

Namespace documents

Desirability, human- or machine-orientation, and useful contents (cf. RDDL)

Error-handling

Importance of clarity in specifying

Hyperlinking practice

Candidates: XLink, RDF, HLink; which are appropriate in which scenarios?