- From: Cantor, Scott <cantor.2@osu.edu>
- Date: Mon, 16 Jan 2012 18:50:14 +0000
- To: "Frederick.Hirsch@nokia.com" <Frederick.Hirsch@nokia.com>
- CC: "eb2m-mrt@asahi-net.or.jp" <eb2m-mrt@asahi-net.or.jp>, "public-xmlsec@w3.org" <public-xmlsec@w3.org>
On 1/16/12 10:58 AM, "Frederick.Hirsch@nokia.com" <Frederick.Hirsch@nokia.com> wrote: > >Is this what you are saying? No, see below. >I don't think there is a problem with the xenc 1.1 schema file itself, as >MGF is defined as a stand-alone type in the xenc11 namespace. Do you see >a problem with the 1.1 schema file (attached)? No, I think the issue is with the way the fragment is laid out inside the spec. >The document also highlights the schema definition in 5.5.2: >Schema Definition: > <!-- use these element types as children of EncryptionMethod >when used with RSA-OAEP --> > <element name="OAEPparams" minOccurs="0" type="base64Binary"/> > <element ref="ds:DigestMethod" minOccurs="0"/> > <element name="MGF" type="xenc11:MGFType"/> This isn't really a normative schema, and I think that's the problem here. It's presented in a questionable way because it's trying to show the content model that is imposed by the text, but there is no actual schema enforcing this. And as it stands, it's misrepresenting the MGF and OAEPparams elements because it's giving them both "names" in the same default namespace. Basically you can't informally present things like this without running into problems. At the very least, it shouldn't be called a "Schema". I'm not sure what can really be done here, but at a minimum you'd have to maybe split the schema fragments being presented in the two separate schemas. Personally, I would just use prose to describe the element content, and then maybe just show the schema for the new element being defined here, the MGF. -- Scott
Received on Monday, 16 January 2012 18:52:02 UTC