empty KeyInfo, etc.


I have one express dislike and a few trivial clarity concerns with
some of our schema defs, all related to the use of minOccurs and

These comments are based on the standingless

4.4 KeyInfo

<complexType name="KeyInfoType" mixed="true">
  <choice maxOccurs="unbounded">     
    <element name="KeyName" type="string"/> 
    <any ... namespace="##other" minOccurs="0" maxOccurs="unbounded"/> 
This permits an empty KeyInfo (if you have 0 elements from
##other). It seems to me that if we took minOccurs=0 and
maxOccurs=unb away from the any, then the unlimit on the
choice would permit exactly what we want to express: 1 or
more elements among our permitted types and those of others.

This is consistent with the new X509DataType, etc.

Other issues:

4.3.2 SignatureMethodType

The minOccurs=0/maxOccurs=1 on the sequence are redundant. TransformType

The maxOccurs=unb on the choice is redundant or in error?
It suggests that multiple XSLT or XPath elements are valid.

4.4.6 SPKIData

The maxOccurs=unb on the outer sequence allows multiple
SPKISexp elements, which I don't believe is the intention.
I think instead the any should get that maxOccurs.

4.5/5.1 Object/Manifest

ObjectType has sequence+[any], where ManifestType has
sequence[any+]; I think the latter is more consistent with
the rest of the doc.

5.2 SignatureProperties

SignatureProperType has choice*[any*]; one of the * is


Baltimore Technologies plc will not be liable for direct,  special,  indirect 
or consequential  damages  arising  from  alteration of  the contents of this
message by a third party or as a result of any virus being passed on.

In addition, certain Marketing collateral may be added from time to time to
promote Baltimore Technologies products, services, Global e-Security or
appearance at trade shows and conferences.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.

Received on Monday, 5 March 2001 05:19:53 UTC