Hi,
>The minOccurs="0" of Base64Content could be dropped and the maxOccurs='1' too. The sequence already got a minOccurs="0".
Yes.
BR,
dh
Von: dss-x@lists.oasis-open.org <dss-x@lists.oasis-open.org> Im Auftrag von Andreas Kuehne
Gesendet: Montag, 21. Januar 2019 22:04
An: dss-x <dss-x@lists.oasis-open.org>
Betreff: [dss-x] Details regarding the construction of ds-rw:DigestMethodType
Hi all,
sorry that I wasn't able to explain the construction principles of ds-rw:DigestMethodType right away in our call ... but having a second look at the structure everything's quite obvious:
The original XMLDSig type :
<complexType name="DigestMethodType" mixed="true">
ÂÂ<sequence>
ÂÂÂ <any namespace="##other" processContents="lax"
ÂÂÂÂÂÂÂÂÂminOccurs="0" maxOccurs="unbounded"/>
 </sequence>ÂÂÂ
ÂÂ<attribute name="Algorithm" type="anyURI" use="required"/>
</complexType>
Think of JSON ... and the pain points are obvious:
The 'mixed' style is NOT supported by JSON (or ASN.1 or ...), so it is substituted by the (lowercase) 'value' string element. It is not mandatory to squeeze random text into your well-designed structure the replacement 'value' is a 0..1 element.
The next ugly guy is the 'xs:any', replaced by a sequence of 'xs:base64Binary' elements. Just a single 'xs:base64Binary'we presumed as _not_ sufficient to replace an unbound sequence of xs:any . So we end up with
<xs:complexType name="DigestMethodType">
<xs:sequence>
<xs:element name="value" type="string" minOccurs="0" maxOccurs="1"/>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="Base64Content"
type="xs:base64Binary"
minOccurs="0"
maxOccurs="1"/>
</xs:sequence>
</xs:sequence>
<xs:attribute name="Algorithm" type="anyURI" use="required"/>
</xs:complexType>
The minOccurs="0" of Base64Content could be dropped and the maxOccurs='1' too. The sequence already got a minOccurs="0".
The third bloke in that gang of obstacles is not used here: The XPath / XPointer _expression_. The syntax inside relies upon the namespace prefixes declared in the surrounding document. This is again an 'XML-only' show so the NSPrefixMapping component was introduced to explicitly declare the translation of a prefix to a namespace.
These three trade-offs of the multi-syntax approach are described in the new core in section 2.2, including the sample of 'ds:Transform' to show the changes with a real-world object. I tried to explain the reasoning for this approach as good as possible there. Please take a look whether we can improve this part in any way. I do assume that it will alienate any XML-used reader.
Greetings,
Andreas
--
Andreas KÃhne
phone: +49 177 293 24 97
mailto: kuehne@trustable.de
Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612
Director Andreas KÃhne
Company UK Company No: 5218868 Registered in England and Wales