[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Manifest inclusion issue
Amazing. Here I go again... I go for optional whenever possible, WRT whether it has to be present in every message. I go for mandatory whenever possible WRT whether it has to be supported if present. Kit. firstname.lastname@example.org wrote: > > I go for mandatory rather than optional wherever possible. > John > > MQSeries Technical Strategy & Planning, > IBM UK Ltd, Hursley Park, > Winchester, SO21 2JN > > Tel: +44 (0)1962 815188 > Fax: +44 (0)1962 816898 > Notes Id: John Ibbotson/UK/IBM > email: email@example.com > > Nicholas Kassem <Nick.Kassem@eng.sun.com> on 14/04/2000 03:27:37 > > Please respond to Nicholas Kassem <Nick.Kassem@eng.sun.com> > > To: Scott Hinkelman/Austin/IBM@IBMUS > cc: "ebXML Transport \(E-mail\)" <ebXML-Transport@lists.oasis-open.org> > (bcc: John Ibbotson/UK/IBM) > Subject: Re: Manifest inclusion issue > > I agree with your point. We can always back-off the mandatory elements > later. > > Nick > > At 09:11 PM 4/13/2000 -0500, firstname.lastname@example.org wrote: > > >My view is that at this point in the game, when any aspect of the > >optionality issue > >comes up I will lean toward mandatory. This is based in the fact that > >in early versions of specifications it is always better to be restrictive > >and mandatory, > >as specifications can generally become less restrictive over time without > >breaking existing implementations. > >One inevitable downfall to this policy (on questions of optionality in > >initial versions) > >is that when structures are required that must be filled in (say an > >attribute), > >implementations may be forced to load garbage if not really needed. This > is > >always > >a give and take call considering flowing "perhaps never really needed" > data > >(applicable here), but > >this negative generally does not out-weigh protection against future > >implementation > >breakage, especially in initial versions. > > > >Although this is a case of existance a distinguished container and not an > >optional value issue, > >without the "garbage issue", I would lean toward making it mandatory > mostly > >out of consistent policy. > > > >Thanks, > >Scott R. Hinkelman > >IBM Austin > >SWG Java Solutions > >XML/Java Standards Architecture > >Office: 512-823-8097 TL793-8097 > >Home: 512-930-5675 > >Cell: 512-940-0519 > >email@example.com > >Fax: 512-838-1074 > > > > > > > >Nicholas Kassem <Nick.Kassem@eng.sun.com> on 04/13/2000 04:32:17 PM > > > >To: "ebXML Transport \(E-mail\)" <ebXML-Transport@lists.oasis-open.org> > >cc: > >Subject: Re: Manifest inclusion issue > > > > > > > > > >Just so that I'm on the same page. A <null> payload is *explicitly* > denoted > >by the absence of Manifest details - the Manifest itself is present. > >Agreed ? > > > >Nick > > > >At 04:57 PM 4/13/2000 -0400, Nikola Stojanovic wrote: > > ><David> > > >I think that, in both examples, option 2 is the better XML style. > > ></David> > > > > > >I agree (not only XML style). In 2. we have consistent relationship by > >value > > >and in 1. we have relationship by value/existence (where existence is an > > >exception). If I recall correctly, this is in line with Ian's, Chris's > and > > >others' feelings about mandatory manifest. This might be a design rule > for > > >the whole ebXML? > > > > > >Nikola > > > > > > > > > > > > > > > > > > > > > > > -- _/ _/ Kit C. J. Lueder _/ _/ _/ The MITRE Corp. Tel: 703-883-5205 _/_/_/ _/ _/_/_/ 1820 Dolley Madison Bl Cell: 703-577-2463 _/ _/ _/ _/ Mailstop W722 FAX: 703-883-7996 _/ _/ _/ _/ McLean, VA 22102 Mail: firstname.lastname@example.org Worse than an unanswered question is an unquestioned answer.
Powered by eList eXpress LLC