W3C home > Mailing lists > Public > www-tag@w3.org > March 2002

Re: Re[2]: section 1, intro, for review

From: <noah_mendelsohn@us.ibm.com>
Date: Tue, 19 Mar 2002 14:21:12 -0500
To: Chris Lilley <chris@w3.org>
Cc: Mark Baker <distobj@acm.org>, www-tag@w3.org
Message-ID: <OF275FA245.EF4B1A8A-ON85256B81.00698D53@lotus.com>
Chris:  I think you've set down a very nicely balanced re-expression of 
what I was trying to say.   I especially like:

>> The useful balance point is to have a small 
>> selection of common protocols and to invent 
>> new ones when necessary.

I think we're close to converging, but I would still quibble a bit with:

>> but to argue (which I don't think you are, 
>> but just to be sure) that there should be no 
>> mention of XML in case it gets replaced in 20 years
>> leave a minimal, and uselessly impractical, architecture.

Well, I think I'm suggesting a layered approach to the architecture, with 
one document (or set of docs) that sets down the principles that are truly 
foundational to the web.  We should expect the rules captured there to 
last indefinitely, with only occasional evolutionary change. I see URI's 
as fundamental, but not HTTP or XML.  I'm unsure about scheme names as a 
means of dividing the protocol space and the name space (e.g. http:). They 
seem to be a foundational aspect of URI's, but we know that they have some 
limitations and may need to be revisited at some point.  I suspect schema 
names (as a concept, not individual ones) make the cut.  I would probably 
include REST as a foundational principle to be applied to the subset of 
resources that model well as a distributed memory (I know there is 
unresolved debate, and some believe it applies to more than that.)

I would then layer on that documents that describe the web architecture as 
we have deployed it.  That's where I'd put http, XML, etc.   The Web can 
fundamentally exist without XML, IMO.  It did before and it could again.

Just for comparison, if I were writing the Internet archtecture in this 
style, IP and IP addresses would be in the foundation layer, but TCP would 
not.  I think the Internet would still be the Internet if TCP were 
replaced.  If IP turned into virtual circuits, I think that would be a 
completely different system.

So, a layered archtecture.  No mention of XML in the foundation, but lots 
of emphasis in the next layer up.  That's what I'd suggest anyway.

Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142

Chris Lilley <chris@w3.org>
03/18/2002 05:46 PM
Please respond to Chris Lilley

        To:     noah_mendelsohn@us.ibm.com
        cc:     Mark Baker <distobj@acm.org>, www-tag@w3.org
        Subject:        Re[2]: section 1, intro, for review

On Monday, 18 March, 2002, 23:00:30, noah wrote:

nuic> Mark Baker writes:

>>> I would prefer it if the special role of HTTP was at least alluded to.

nuic> This is a point which Mark and I have occasionally discussed  in 
nuic> No doubt, HTTP plays a distinguished role in the Web today and for 
nuic> forseeable future.  Still (and I suspect Mark doesn't agree) I don't 
nuic> why our architecture should imply that the web would diminished in 
nuic> if HTTP were eventually displaced by other protocols.  Indeed, I see 
nuic> possibility of evolution as important to allow for changing 
nuic> new hardware/software, and to enable access to more diverse sorts of 

nuic> resources over time.


nuic> If we didn't have universal  naming, there would be no web;  if the 
nuic> deployed protocols evolve over time, I think we're fine.   Thus, and 
nuic> know this is controversial, I prefer a formulation in which the 
nuic> foundational web architecture is just URI's, with no particular 
nuic> or schemes distinguished or preferred.

I agree with your first point but conclude that the second is too 

nuic> Whatever protocols we deploy at this or that point in time are to 
nuic> interoperability for access to  (representations of or information 
nuic> resources.  If the TAG wants to write a separate document on "Web 
nuic> architecture in 2002", I think http should indeed be identified 
there as 
nuic> playing a distinguished role.

I think this division into "unchanging web architecture" and "best
current practices" is a useful one, but the cutoff date from one to
the other is vague. Its possible to derive or extrapolate the former
from the latter, (and that is my preferred method of reality checking
top-down, theoretical approaches to architecture) but the period of
currency of best practice is uncertain.

For example, saying that markup should use XML, or XML 1.0,
or XML 1.0, or XML 1.0 SE have different periods of usefulness; but to
argue (which I don't think you are, but just to be sure) that there
should be no mention of XML in case it gets replaced in 20 years would
leave a minimal, and uselessly impractical, architecture.

So I am happy to note that <i>currently</i>, HTTP enjoys widespread
use; that new applications should use it rather than needlessly
inventing new protocols, etc. I agree this might change, but I would
not want to restrict it to a particular date range because we don't
know in advance what range that is.

There is also a practical point, the tension between innovation and
conservatism which penalizes moving too far in either direction; its
all very well to say that new protocols can be invented, and so they
can, but if every single document uses a new protocol we are in
trouble. Likewise if we were to force pop, smtp, irc etc to all use
HTTP. The useful balance point is to have a small selection of common
protocols and to invent new ones when necessary.

Which all seems self evident, I guess, but worth noting to guard
against the unlikely extreme of a top-down approach that either bans
all mention of HTTP, or alternatively mandates it everywhere.

 Chris                            mailto:chris@w3.org
Received on Tuesday, 19 March 2002 14:38:33 UTC

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