- From: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>
- Date: Wed, 24 Mar 2004 10:56:49 +0100
- To: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Cc: Jacek Kopecky <jacek.kopecky@systinet.com>, Noah Mendelsohn <noah_mendelsohn@us.ibm.com>, XMLP Dist App <xml-dist-app@w3.org>
Hum... it's not my recollection and I don't see this in the minutes[1] either. Did I miss something obvious? If we were indeed to use @relay="true", there would be no need for a special role, and we could simply use "next", as was suggested initially by Noah. In addition, as Hervé reminded us recently, @relay only helps when a header block was understood but NOT processed. @relay does not help when the header block was indeed processed. This is where we need the additional semantics provided by "sticky" (or whatever it ends up being called), i.e. always reinsert even if processed. Actually, it now really looks to me like we are augmenting our processing model with this new role. I don't think it's Representation header specific; hence I prefer the name "sticky" to "reinsertRepresentation". Simply "reinsert" would be ok. Obviously, my closing email was so confusing that it generated a lot of extra discussion. Apologies for not having been clear enough. I'll be attending tonight's telcon. JJ. [1] <http://www.w3.org/2004/03/02-xmlprotocol-irc.txt> Anish Karmarkar wrote: > > The resolution IIRC wasn't quite that. > It wasn't 'always reinserted'. It was -- > > Define a new role (name to be decided) that causes a Representation > header block targeted to it be reinserted if processed. > > (removed the always). > It is always reinserted only if relay is also true. > > -Anish > -- > > Jean-Jacques Moreau wrote: > >> >> What about the following amendment to your point 1? >> >> <amendment> >> Define a new role (name to be decided) that causes any Representation >> header block targeted to it to always be reinserted, even if processed. >> </amendment> >> >> Jacek Kopecky wrote: >> >>> Oh, I think your closing email [1] is a bit wrong and a bit confusing: >>> >>> it says the five numbered points are characteristics of the new role, >>> where only the second is, in fact. The first point isn't true (IIRC), >>> the use of the new role is totally up to the application; a >>> Representation header can be targeted at any other role and the usual >>> rules apply, including the points 3a, 3b and 4 in the closing email. >>> >>> I think the closing email should be rephrased to something like: >>> >>> >>> At its recent f2f, the XMLP WG decided to close this issue with >>> the following actions: >>> 1. define a new role (name to be decided) that causes >>> all >>> Representation header blocks targeted to it always to be >>> reinserted, even if processed. >>> 2. Note that it's OK for multiple Representation >>> header blocks >>> in the same message to have the same URI and role. Such >>> Representation header blocks would typically have different >>> metadata. >>> 3. Note that implementations MAY need to process >>> Representation >>> header blocks BEFORE other header blocks that might dereference >>> URIs. >>> >>> >>> Best regards, >>> >>> Jacek Kopecky >>> >>> Systinet Corporation >>> http://www.systinet.com/ >>> >>> >>> [1] http://lists.w3.org/Archives/Public/xmlp-comments/2004Mar/0024.html >>> >>> >>> On Mon, 2004-03-22 at 16:56, Jean-Jacques Moreau wrote: >>> >>>> Yes it does! The (agreed) resolution says: "Define a new role as >>>> above [plus other stuff]". >>>> >>>> "Above" says: "Proposal (again): Define a new role. Characteristics >>>> of this role are; 1. if you process a Rep header targetted at this >>>> role, you MUST resinsert it." >>>> >>>> If point 1. was not to be taken into consideration, why would the >>>> agreed resolution say "as above"? My reading is that the scribe >>>> figured out it could save some typing, instead of reinserting >>>> (again) the whole proposal once more. >>>> >>>> You seem to be thinking otherwise. >>>> >>>> JJ. >>> >>> >>> >>> >>> >> >> >
Received on Wednesday, 24 March 2004 05:02:32 UTC