Response to Question 1. Re: [dss-x] Feedback on the use of the DSS visible signature profile

[Stefan Drees <stefan@drees.name>]

Dear Ernst Jan,

here now a first real feedback from my side trying to address your first 
issue and some suggestions as response from me.

Since these input/output containers structures in Section 2.7 of the 
core are optional from the point of view of the core itself, I would 
expect some kind of <xs:all> ... </xs:all> as skeleton container for the 
validation of the **required** profile specific content inside the 
OptionalInputs / OptionalOutputs **if sequence does not** matter, but 
the presence **does**.

In other profiles I skimmed through <sequence></sequence> constructs 
have been used in the profiles defining xsds (I presume this is what you 
meant with "Usually, an XSD defines elements in a particular order" in 
your comment below.

I do not know if implementers would be assisted substantially by the 
core ammending the requirement, that if two elements or more MAY be 
contained inside these containers these MUST obey a certain ordering 
relation based on the element names in utf-8 ("alphabetically").

What do the *real* implementers think?

All the best,
Stefan.

Am 14.05.12 15:23, schrieb Ernst Jan van Nigtevecht:
> ...
> Related to the DSS Core:
>
> (1) Regarding message validation by means of XSD's: The OptionalInputs /
> OptionalOutputs are defined as anyType. The OptionalInputs and
> OptionalOutputs can appear in any order:
>
> DSS-Core Line 615: "Applications MUST be able to handle optional inputs
> or outputs appearing in any order within these elements. Normally, there
> will only be at most one occurrence of any particular optional input or
> output within a protocol message."
>
> Usually, an XSD defines elements in a particular order. Consequently,
> you cannot define an XSD for this. To validate a request, the part of
> the OptionalInputs will always succeed, even though the actual sub-tree
> does not adhere to a specific optional input XSD.
>
> Question 1:
> The XSD of a particular OptionalInput / OptionalOutput will be
> specified, but how can one easily validatie a message using the dss xsd
> and the profile specific xsd? It currently seems that you have to
> manipulate the dss xsd to incorporate the OptionalInputs xsd (leaving
> out the anyType for the OptionalInput, but that invalidates "any order").
>
> It could have been stated that the order of the OptionalInputs /
> OptionalOutputs has to be alphabetically.
>
> What is the experience of other implementers?
> ...

Attachment: smime.p7s
Description: S/MIME Kryptografische Unterschrift