W3 TAG

Architecture Categorization

This is a division of the architecture into areas, as a working space for the TAG.

Status

This is not a formal document in any sense, nor a working draft of the W3C. It is a working space for the TAG. Like all categorizations it is to a certain extent arbitrary. The tree structure below does not in any way dictate an order of writing the documents. This is not a formal document. It is more like a group note-book. It changes continually.

$Id: toc.html,v 1.61 2002/06/06 17:33:46 ijacobs Exp $

Conventions

Colored backgrounds indicate the type of resource being linked. These are the sorts of things which one should treat as homework before a discussion on the topic.

"@@" Means to be fixed. Numbered subsections indicate suptopics. Bullets indicate related material.

1. Introduction

The web is a medium through which people and machines communicate using shared langauges. Interoperability - the ability of different people and machines to communicate -- comes about thanks to shared, often standardized, specifications of languages. These web architecture documents, by putting the various specifications into relationship with each other, and answering some open questions between them, aim to give an overall understanding of the working of the web.

2. What does a URI identify?

The information space exists as a mapping between URIs and the things they identify.

  1. What you cannot assume (persistence, uniuqueness, etc; no peeking, etc,)
  2. With a #fragid (Save the fragid and hand it to whatever you get from the document)
  3. Without a #fragid: It depends on the scheme
    1. http: scheme - generic resources. General outline
      • Some modeling of relationships between specifiuc and general resources
    2. mailto: A generic concept of a mailbox, not a user action
    3. .... other schemes@@
    4. When to and when not to make a new URI scheme

3. How do we convey information?

A subset of URIs identify documents. We represent information using strings of bits. We make up representations - langauges - and write specs which explain what bits in that language mean, and we identifiy these languages with URI. The question becomes: What does a (MIME type, bits) pair mean?

  1. MIME type authorizes reader to infer meaning of bits
  2. The rest is specfic to MIME types
    1. HTML, SVG - human readable documents
      1. Meaning is that one would expect an human to understand
      2. Principle: Separation of form and content; device independence; Acc'y.
    2. RDF - more formally defined semantics
      1. Specifiction of Property or Class defines semantics
    3. Generic XML - according to namespace of outer element
      1. Character encoding issues
      2. Mixed namesapces:
        1. plugins in graphic types
        2. template/function systems (XSLT, Xinclude,XQuery?)
        3. invariants - what can't an embedded thing change?
      3. Whether to give namespace as a MIME attribute
      4. XML Digital Signature: beware of attributing meaning
        1. External agreement defines the meaning of signature
        2. Beware apparent meaning and signature of not XML docs
      5. Common data types
        • Interpretation Properties
        1. Commonality agreed between RDF and XML
        2. Data type model in Web Ont
    4. Encrypted document
      1. After decryption, what is the result?
    5. Multipart (MIME or XML package or DIME)
      1. No meaning of attachments except as given in cover note
  3. Internationalization

4. State Transfer (title?)

How the illusion of the web is maintained using the Internet. HTTP is a protocol which allows state to be distributed across the Internet, giving certain guarantees of validity for that URI-document mapping

  1. "Snapshot mode" - the approximation of the web ignoring change
  2. HTTP as a protocol for implementation of REST
    1. Expiry, etc proxy rules and consistency (formal model?)
    2. Use and abuse of GET
      • Need or not for QUERY

5. What does a message mean?

All the above centers around the web as a space of things, and a quasi-static distribution of the state of those things. remote operations are considered only as a means to an end. However, remote operations surfcaed at the application level, as RPC or nor as Web Services, are important part of the Internet architecture. In this section, specs define protocols in terms of the contents of messages, just as above, specs define the content of documents in terms of message protocols.

  1. general concept of message (sender, recipient, datetime, document)
  2. RFC822-style messages
    1. Resolution of semantics of existing headers (possible?)
      • Formal model?
      • Practical syntax of To: headers, etc?
    2. Extensions
    3. Whether to extend headers or enclose richer message format
  3. HTTP as a protocol for messages
  4. Web services messages
    1. Use of XML as message rather than document
    2. Mapping XML Protocol to other RPC systsems - CORBA etc
    3. Meaning of messages in context of others
      • Modeling protocols (WSCL etc etc)

    4. meaning of a message with Routing information
    5. meaning of a message with @@@
  5. Protocol analysis
  6. What is the meaning of an attachment in email?

    (DIME or multipart-related: nothing unless referred to in the cover note)


Last change $Id: toc.html,v 1.61 2002/06/06 17:33:46 ijacobs Exp $

Timbl, TAG draft orking space only

Administation for this page