- From: Anish Karmarkar <Anish.Karmarkar@oracle.com>
- Date: Wed, 24 Mar 2004 09:15:14 -0800
- To: Pete Hendry <peter.hendry@capeclear.com>
- Cc: Jean-Jacques Moreau <jean-jacques.moreau@crf.canon.fr>, Jacek Kopecky <jacek.kopecky@systinet.com>, Noah Mendelsohn <noah_mendelsohn@us.ibm.com>, XMLP Dist App <xml-dist-app@w3.org>
Pete Hendry wrote: > Could @relay be changed to an enumeration of "always", "never", > "processed", etc. Is there a finite set of values it could take to > convey the intention of @relay and @sticky? This could remove the need > for 2 attributes related to relaying the header. "sticky" is not a new attribute but a value for the role attribute. > > Pete > > Jean-Jacques Moreau wrote: > >> >> 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 17:06:25 UTC