Re: [bt-spec] Face-to-face

[Mark Little <mark_little@hp.com>]

Great. Many thanks.

Mark.

----- Original Message -----
From: "Geoffrey Brown" <Geoffrey.Brown@oracle.com>
To: "Mark Little" <mark_little@hp.com>
Cc: "BT - spec" <bt-spec@lists.oasis-open.org>
Sent: Thursday, May 02, 2002 7:53 PM
Subject: Re: [bt-spec] Face-to-face


> Mark,
>
> This is all reasonable to I  .. you will have a revised submission by next
> Thursday.
>
> Geoff.
>
> Mark Little wrote:
>
> >  Gladly risking being seen as the "bad guy" again in this issue, here's
what
> > I'd like to see in order to expediate a decision on issue 89 at the
> > Newcastle f2f:
> > Prior to the face-to-face I'd like to see a detailed description of
> > *exactly* what the issue is (including a use case) and why the proposal
> > solves this. We've already agreed that we need to see this at least a
week
> > prior to the meeting before we can even consider voting on this issue.
What
> > I don't want to happen at the face-to-face is for it to degenerate into
a
> > "find the use case" situation; assuming that state serialization appears
to
> > be a valid requirement, then if it is at all possible to address the
> > use-cases in another way within the current bounds of BTP I think we
should
> > not vote on the issue at the face-to-face, rather than run the risk of
> > voting and having a no vote (OK, this is definitely a personal opinion).
If
> > we were not up against a hard deadline and this sort of thing happened,
then
> > we'd do what we have done at previous meetings: told individuals to go
away
> > and come back at a later meeting with an updated proposal for
> > re-consideration; we don't have that luxury now. If the committee
decides to
> > vote anyway then that's OK, but presumably that's it as far as state
> > serialization goes in *any* version of the specification? (Not sure
about
> > procedure here, so I'm more than happy to be corrected on this one, but
> > given what happened in the past with regard to certain BEA proposals I'd
> > have to assume I'm right.)
> >
> >  The reference to "find the use case" is simply that if we can address
all
> > of the proposed use cases within current BTP then we again run the risk
of
> > people trying to come up with other use cases on the fly to justify the
> > proposal. To then expect the committee to look at these and determine
> > whether or not they are actually new and can only be addressed by this
> > submission is not realistic IMO. This is the reason we've asked for
*full*
> > issue text a week prior to the meeting; otherwise we may as well just
wait
> > for everything until the face-to-face. I'd like to have all text that is
> > necessary to consider this issue on my desk 7 days prior to the
> > face-to-face: if that's not possible then perhaps it is an indication
that
> > the issue is not fully thought out.
> >
> >  It is also ridiculous to say that this issue has no impact on the rest
of
> > the specification. First of all, it could be said that if it has no
impact
> > then why do we need it?! Secondly, as I've said on several occassions,
and
> > I'll try to put it another way this time, this is a bit like a product
> > developer saying "we'll add this feature to this release as a place
holder
> > and we won't document it much as we don't expect people to use it much,
and
> > in a later version we'll come back and fix it; it'll not cause us any
> > problems." Then later when they find that the place holder is
insufficient
> > for their requirements, they find that someone(s) has actually used the
damn
> > thing and now relies upon it such that changing it is out of the
question -
> > must remain compatible. So, now they either have to not put in place the
> > real solution using this "place holder" or they basically have to add
> > something else which does the right thing but (probably) duplicates some
> > (much) of the work of the place holder. And all because they wanted a
place
> > holder for a feature they were going to add later.
> >
> >  So, let's forget about this place holder red herring that people have
been
> > mentioning in emails (as I've said before, it's a weak "argument" for
adding
> > anything to any specification): there either is, or is not, a problem
and
> > therefore their either is, or is not, a solution for it. If there really
is
> > a requirement for this then I for one will vote for it. My gut instinct
> > tells me that whatever the problem is, state serialisation is only a
step
> > towards a solution. The questions we need to ask in relation to this
(and
> > have answers for) include a) why do I need to serialise state, b) how do
I
> > serialise state, c) (related to b) on what trigger do I serialise state,
d)
> > how do I get state around, e) are there any restrictions on the use of
this
> > state. I'd be much happier voting on a solution that addressed all of
these
> > aspects rather than on just one.
> >
> >  Finally, saying it's optional is no argument at all. That's exactly
what we
> > don't want in a standard - more options. More options means less
> > compatibility and interoperability. Been there, done that, didn't like
it
> > much!
> >
> >  Mark.
> >
> > ----------------------------------------------
> > Dr. Mark Little, Distinguished Engineer,
> > Transactions Architect, HP Arjuna Labs
> > Email: mark_little@hp.com
> > Phone: +44 191 2606216
> > Fax  : +44 191 2606250
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
>
>