- From: David Orchard <david.orchard@bea.com>
- Date: Mon, 18 Mar 2002 16:10:41 -0800
- To: "'Simon St.Laurent'" <simonstl@simonstl.com>, <www-tag@w3.org>
Actually, to me it's more of an expansion of the scope of the web. I'd rather have a more inclusive web, that includes different models. The invarients are more to do with the uniformity of access aspects, particularly URIs and XML, imo. To a certain extent, I think that adding on XML started the evolution to additional processing/information models. With the restrictiveness of HTML, a shared information model makes a lot of sense. I also tend to think that information models and processing models are quite related. But with XML, I can have one document that might target different resources/components with sub portions of the document. So the Extensible part of XML meant we can develop extensible information or processing models. So I find it not suprising at all that changing one variable (adding extensible data interchange models via XML) means a change to a different variable (adding different information models to a single information model). Often these changes happen in ways we didn't expect - law of unintended consequences. That's the way architectures and other things evolve. I'd prefer a web with principles that evolve. At a deeply personal level, that's the primary reason I ran for the TAG. Cheers, Dave > -----Original Message----- > From: www-tag-request@w3.org > [mailto:www-tag-request@w3.org]On Behalf Of > Simon St.Laurent > Sent: Monday, March 18, 2002 4:37 PM > To: www-tag@w3.org > Subject: RE: section 1, intro, for review > > > On Mon, 2002-03-18 at 18:23, David Orchard wrote: > > Noah and I share the viewpoint that protocol evolution is a > good and natural > > thing. My reason is because I don't think that the > everything that we want > > to do in the future should be modeled as propagation of a > shared information > > space. For example, the assumptions of cardinalities of identified > > resources might not hold. Adn the propagation issues may > be different > > depending upon the application. A concrete example that I > like is thinking > > about reliable delivery of a stock quote message. From the > queue software's > > perspective, this is a POST. But from the stock quote applications > > perspective, this is a GET. So I want to POST a GET request ;-). > > > > Perhaps the real issue isn't http, but whether a shared > information space is > > the way that we should think about future applications that > we want to > > build. > > Is it fair to question whether that kind of evolution is in fact > evolution away from the Web? > > I'm not arguing that it isn't worth pursuing in general, but a shared > information space seems pretty fundamental to notions of the Web. > > -- > Simon St.Laurent > Ring around the content, a pocket full of brackets > Errors, errors, all fall down! > http://simonstl.com > >
Received on Monday, 18 March 2002 19:12:48 UTC