- From: Mark Jones <jones@research.att.com>
- Date: Wed, 21 Mar 2001 18:38:14 -0500 (EST)
- To: mnot@akamai.com, moreau@crf.canon.fr
- Cc: frystyk@microsoft.com, jones@research.att.com, skw@hplb.hpl.hp.com, xml-dist-app@w3.org
From mnot@akamai.com Wed Mar 21 12:00 EST 2001 Delivered-To: jones@research.att.com Date: Wed, 21 Mar 2001 09:00:14 -0800 From: Mark Nottingham <mnot@akamai.com> To: Jean-Jacques Moreau <moreau@crf.canon.fr> Cc: Mark Jones <jones@research.att.com>, skw@hplb.hpl.hp.com, frystyk@microsoft.com, xml-dist-app@w3.org Subject: Re: Finalised Glossary Definitions Mime-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.2.5i On Wed, Mar 21, 2001 at 03:44:54PM +0100, Jean-Jacques Moreau wrote: > > We've tended to ignore the constructive side, but there must be > > some API for the sender which takes a relatively high-level > > characterization of the required behavior and manufactures the > > appropriate blocks. This API should be modular so that > > independent blocks can be inserted and targeted independently, > > while still permitting any necessary dependencies (e.g., > > ordering). > > I can see Henrik frowning his eyes... :) But yes, seriously, there > will need to be an API There will certainly need to be an API somewhere (perhaps even standardized), but I hope this isn't meant to imply that this work is in scope for this group. I don't mean to imply that the API would be in scope, but that the functionality that it implies at the XMLP layer has to be thought about. It also might shed some light on how our notion of module manifests itself on the sender side. We've tended to think about how a processor finds a handler to process a block, and very little about how a block gets generated in the first place. --mark Mark Jones AT&T Labs Cheers, -- Mark Nottingham, Research Scientist Akamai Technologies (San Mateo, CA USA)
Received on Wednesday, 21 March 2001 18:38:19 UTC