Re: [ebxml-bp] Updates to Signals schema for version 2 BPSS, and2 questions.

[David RR Webber <david@drrw.info>]

Dale,

+1

Makes sense to me.

DW

Dale Moberg wrote:

> 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).
>