Updates to Signals schema for version 2 BPSS, and 2 questions.

["Dale Moberg" <dmoberg@cyclonecommerce.com>]

Hi

 

The previous 1.x signal schema contained a minor problem discovered by the Oxygen validater.

Consider

 

<xsd:sequence>

   <xsd:element ref="sig:NonRepudiationInformation" minOccurs="0"/>

   <xsd:element ref="ds:Signature" minOccurs="0"/>

   <xsd:any namespace="##other" minOccurs="0"/>

</xsd:sequence>

 

For the above sequence (part of 2 complexTypes), there is a violation of the unique particle attribution, which the schema specification explains as:

 

“A content model must be formed such that during ·validation· of an element information item sequence, the particle component contained directly, indirectly or ·implicitly· therein with which to attempt to ·validate· each

item in the sequence in turn can be uniquely determined without examining the content or attributes of that item, and without any information about the items in the remainder of the sequence.”

 

So because the any element is for ##other namespaces, when an element is not in the target namespace, such as ds:signature, then there can be an ambiguity in parsing. For example, when just a signature is present, it could be parsed as a sequence with the first 2 sequents occurring 0 times, and the any element occurring once. Or it could be parsed as the first element 0 occurences, the second 1 occurrence, and the any 0 occurences.

 

I discussed this with Hima and he and I both think the easiest change is to remove the any element, and that is basically what is done in the draft schema attached.

 

Some other minor changes were made to make the schema conform with the core BPSS schema.

 

One issue is whether an @id attribute should be added to elements to allow BPSS Specification elements to refer to elements using URI-references (or fragments).

At present, location just provides a URL for the schema for example and not an element within the schema.

 

A second issue is whether the Exceptions should have their own uniquely named elements or use the current approach of just have one Exception element defined with three flavors (AcceptanceAcknowledgementException, ReceiptAcknowledgementException, and GeneralException).

ebBP-Signals-2_x.xsd