Re: Manifest inclusion issue

[srh@us.ibm.com]

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