Minutes of CPPA Negotiation Conference Call Dec. 3, 2003

Attendees: Martin Sachs, Monica J. Martin, Sacha Schlegel

Monica introduced the white space problem that was originally raised on the list by Sacha. In the Negotiation BPSS instance document, the value of the name attribute of the BusinessDocument element and other elements may have embedded blanks. There is no control on how many successive blanks may appear. This leads to the possibility of failed comparisons because the run-time software, for example, may assume 1 blank but the instance document might contain more than one successive blank. The question is where is the responsibility for dealing with this mismatch? Currently, it is up to the run-time programmer to deal with this. Sacha had pointed out that the XML Schema specification provides a parameter which tells a parser how to handle multiple blanks. One setting is for the parser to compress strings of blanks to a single blank when returning a string. It had been proposed that the BPSS schema specify “compress blanks” so that programmers can count on the parser always compressing blanks to a single blank in returning a string. An objection to this proposal had been raised that this constitutes defining parser operation.

Marty: It is not likely that any string in the BPSS instance document would need more than one successive blanks. He suggested that more than one successive blank would only be needed for purposes such as an application’s defining a set of strings such that their contents could be printed in neat columns.

Marty: If it is correct that XML Schema provides for specifying how multiple blanks are to be handled by a parser, then specifying the setting of that parameter in BPSS is not forcing new parser function unless support of that parameter by parsers is OPTIONAL.

Sacha: The default setting for that parameter is not to collapse blanks to a single blan, which caused the problem of failed comparisons (see above) that he ran into.

Marty: If supporting that parameter is OPTIONAL in XML Schema, then requiring implementers of BPSS to support it fails if not all parsers support it.

Marty proposed the following approach:

· If parsers MUST support the XML Schema compress-blanks parameter, the BPSS specification and schema can require that blanks be collapsed in all string types that involve comparisons.

· If support of the collapse-blanks parameter is OPTIONAL for parsers, or if the BP team does not agree to require that blanks be collapsed, there should at least be a warning in the BPSS specification that run-time software must handle the case of mismatched numbers of successive blanks in strings that otherwise compare equal.

Regarding role reversal (one issue that the BP team is working on), Sacha pointed out that in the Negotiation BPSSS instance document, the roles are reversed only once. Also, each party has only two roles. Monica replied that the BP team will have to consider role reversal more generally than what the Negotiation specification needs.

Monica asked about multiparty collaborations in negotiation. Marty replied that the negotiation SC has not yet considered multiparty collaborations. However the only use for multiparty collaborations that Marty can envision is a negotiation intermediary that has to be explicitly accounted for in the negotiation BPSS instance document and the NCPA.

Monica brought up the question that someone raised about not having a confirmation message from the recipient of the final CPA. She said that Hima Mukkamala had said that this is prevented by a limitation in the current BPSS spec having to do with multiple requests within the same transaction. Monica will formulate a more detailed summary of the problem and post it to the negotiation list.

The meeting was adjourned at 4:45 PM.

Respectively submitted,

Marty Sachs