OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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,

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]