Re: Manifest inclusion issue

["Kit (Christopher) Lueder" <kit@mitre.org>]

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.

john_ibbotson@uk.ibm.com 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: 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
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >

-- 
    _/    _/             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: kit@mitre.org
Worse than an unanswered question is an unquestioned answer.