[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: minutes from Monday morning July 12
Draft minutes from F2F July 12 morning.
----------------
WS-CAF meeting, Oracle, July 12 morning
Martin calls the roll and reviews the agenda. [need attendance data]
Quorate as of slightly after 10 am.
Recommend adoption of June 21 minutes.
Alistair to post minutes from July 5.
Process issues list.
Issue 14.
Discussion: Should be a
consistency issue across specifications. Referencing specs would inherit from
the base type. We need to define some conventions for handling definitions, and
a consistent schema for hierarchically based specifications. We were going to
allow the referencing specifications to define this and specify uniqueness, but
we didn't carry it through consistently. We want unique status values, two
proposals, one where we just use a namespace, and as Keith Swenson proposed you
have a vanilla string with no namespace, but it's implicit in the string. Simeon
prefers the namespace, as does Martin. Mark prefers using the namespace
approach. But in the discussion it turns out that there's broken XML inasmuch as
there's a value definition that needs to change but can't. So the Fujitsu
approach seems more attractive in the end, with a generic string and the
specification defining acceptable values. Could have a namespace attribute.
Summary from Simeon after
the discussion and whiteboard session:
Define a status type as a
string, and it's up to the referencing specs to validate (i.e. values taken
outside schema validation). Can have a namespace as an attribute on the status
type for qualifying the values.
Motion by Simeon, second by
Malik:
Define a status type as an
extension based on string in the schema. The value will not be defined in the
schema but in the referencing specifications. There's an attribute on the types
that specifies the namespace so the values can be uniquely qualified.
Mark discussion: there's
also the completed/completing status. If this solution is good for status,
should the same solution be followed for completion status.
Greg: completion status is
an optional string in a message.
Martin: Should be two
different types but the same rules for each.
Greg: Do we really have
different status types now for completed and the general
status?
Mark: May be situations in
which they are the same but other cases in which they have the same name but
mean different things.
Martin proposes a separate
proposal about completing status - Mark agrees.
Motion carries, one negative
vote.
New Motion: Define an
identical type for completion status.
Mark makes the motion, Malik seconds.
Discussion? Tony - why do we
need two? Mark: Happy enough with what Tony proposed - "completion command"
instead of status for completion.
Amendment to Mark's motion
to define type for command instead of completion status. Completion status is
now completion command but follows the same content model as status, which is a
namespace-qualified string.
Motion carries, one negative
vote.
[Can be a qname, in
clarification to Doug, explanation of the morning's work.]
Issue 47, Martin is going to
come up with something.
Still an action pending on
Martin to discuss with Oracle security experts to get an idea for a proposal.
Issue 59, should be closed
since the specification doesn't use ALSes any more.
Doug brings up Issue 58 -
generally improving the diagrams.
But let's close Issue 59 first.
Malik makes a motion to
close issue 59 with no action. Tony seconds it.
No objections, motion
carries.
Issue 99, we need to do this
but haven't the time at present. Leave open.
Assigned to editors. Need to
discuss timeline as part of the general planning around document completion.
On to Bryan Murray's issue
list. Discussion includes Bryan and reviews changes in the editor's draft
(0.4).
Martin: If the spec isn't
unambiguous about the order of messages, something needs to be added.
Greg sends editor's draft to
the group for discussion, including comments/flags for Bryan's issues.
We don't assume reliable
messaging but it could be layered. Note that Mark's text qualifying Section 2.1
about reliable messaging (Draft .04) is ok.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]