Architectural Principles for a Read-Write Web (?)

Given recent discussion I wanted to get down some high level (abstract)
architectural principles for which writing a read-write web spec should
comply

Here's my list -- see if you think anything should be changed

1. It must enable both reading and writing to the web -- well duh!

2. It must be a standards based approach -- it should conform to existing
standards, reuse is usually better then reinvention

3. It must be back compatible with the existing web

4. It must be compatible with multiple protocols, defined using URIs

5. Two protocols it must work with first are http and file -- both spaces
should be considered part of the web

6. When using the http: space, it must be compatible with the html content
type

7. It must be usable by both humans and machines -- ie data and headers
must be parsable

8. It must be possible to use hyperlinks / URIs in the data structures
supplied, creating an open ended graph -- aka ggg

9. It must take a modular approach which breaks functionality into smaller
pieces -- e.g. identity, identification, authn, authz, storage, payments
with swappable pieces for each function

10. It must be based on existing apps and implementations -- try to
formalize and demo what's in use, rather than create a spec for others to
implement

What do folks think, could this list be a basis to create an architecture,
and then spec?  Is the list too long, too short, mixes too many concepts?

Received on Wednesday, 28 July 2021 12:47:38 UTC