[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Manifest inclusion issue
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: john_ibbotson@uk.ibm.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, srh@us.ibm.com 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 >srh@us.ibm.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 > > > > > > > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC