Re: Confusing schema fragment in Encryption 1.1

I agree

I noted that as well when I looked at it .It is not a schema definition, but an attempt to be helpful. I say we pull this out and rely on the examples as well as showing the new MGF schema.

regards, Frederick

Frederick Hirsch
Nokia



On Jan 16, 2012, at 1:50 PM, ext Cantor, Scott wrote:

> 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 20:34:25 UTC