W3C home > Mailing lists > Public > www-tag@w3.org > May 2003

RE: Proposal for the organization of Chapter 4 of Webarch

From: Bullard, Claude L (Len) <clbullar@ingr.com>
Date: Fri, 30 May 2003 14:49:56 -0500
Message-ID: <15725CF6AFE2F34DB8A5B4770B7334EE022DC396@hq1.pcmail.ingr.com>
To: "'Tim Bray'" <tbray@textuality.com>, WWW-Tag <www-tag@w3.org>

What do you do about nested namespace documents composed 
of aggregate types (eg, must be something other than a 
standard HTML web browser at outermost namespace)?  How 
are these registered?  According to the type of the outermost namespace?
How are multiple encodings handled?

I don't think this one is simple.  I also think it voids 
the notion of the web browser per HTML as the essential 
XML handler for renderable hypermedia/multimedia languages 
with traversable links.


-----Original Message-----
From: Tim Bray [mailto:tbray@textuality.com]
Sent: Friday, May 30, 2003 2:44 PM
To: WWW-Tag
Subject: Proposal for the organization of Chapter 4 of Webarch

I've been reviewing the webarch document heavily and I have a big 
laundry list of mostly editorial issues (will send along).  Then I ran 
heavily into Chapter 4 on "formats" with a dull soggy thud, and realized 
it's made damn little progress in the last year.

So, here's a proposal for how to reorganize it:

4.1. Open-Endedness.

The Web can be used to interchange resource representations in any 
format.  This is a good thing, since there is continuing progress in the 
development of new data formats for new application, and the refinement 
of existing data formats.

Clearly, for a format to be usefully interoperable between two parties, 
they must share certain understandings about its syntax and semantics.

For a format to be widely interoperable across the Web, the following 
must obtain:

- there should be a normative specification which is a stable, 
widely-accessible Web resource.
- the data format should have an officially registered Internet media-type.

Note re cost of inventing a new format rather than re-using an existing 
one.  E.g. it's almost certainly wrong to invent a new format for 
human-readable online display with embedded clickable hyperlinks.

4.1.1 Desirable Characteristics of Format Specifications

- availability online as Web resources
- attention to programmers' needs
- attention to error-handling
- use of examples
- if XML, defined at the Infoset level

4.2 Taxonomic Categorization of Data Formats

This section describes a series of axes which can be used to categorize 
data formats, with a discussion of the related trade-offs and interactions.

4.2.1 Binary vs. Textual

4.2.2 Final-form vs. Reusable
  - e.g. FOP/PDF vs. XHTML/SOAP
  - neither is better, sometimes you *want* final-form

4.2.3 Composable vs. Standalone

  e.g. PDF and RSS 2.0 are not composable
       SVG and XLink are composable
  not entirely orthogonal to final-form/reusable divide

4.3 Presentation/Content/Interaction

4.4 Discussions related to XML data formats

4.4.1 Considerations when to use it (ref IETF doc)
4.4.2 Namespace documents
4.4.3 Fragment identifiers and ID semantics
Received on Friday, 30 May 2003 15:50:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:59 UTC