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.

ws-caf message