OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-transport message

[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]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC