Hi Gerry!
On Thu, Dec 19, 2002 at 12:59:18PM -0500, Gerry Buteau wrote:
Using smidump 0.4.2-pre1 it seems like the minLength and maxLength fields disappear at times.
That is true. If display hints are present they will be converted to regular expressions in the "pattern" tag and "m**Length" will not be specified for avoiding redundancy.
I've included two examples...
[...]
TradiusSecret ::= TEXTUAL-CONVENTION DISPLAY-HINT "32a" STATUS current DESCRIPTION "A secret shared between the RADIUS server and a RADIUS client or another RADIUS server." SYNTAX OCTET STRING (SIZE(1..32))
[...]
<xsd:simpleType name="TradiusSecret"> xsd:annotation xsd:documentation A secret shared between the RADIUS server and a RADIUS client or another RADIUS server. </xsd:documentation> xsd:appinfo <displayHint>32a</displayHint> </xsd:appinfo> </xsd:annotation> <xsd:restriction base="xsd:string"> <xsd:pattern value="(((#x00-#x7f)){1,32})"/> </xsd:restriction> </xsd:simpleType>
[...]
**Question : Why aren't "minLength" and "maxLength" nodes included? Seems like smidump knows about them, because they are used for the pattern.
In the above example the range restriction (SIZE(1..32)) is coded in the "pattern". Using "minLength" and "maxLength" would mean having redundancy in the schema. The same applies to the example below.
[...]
subscriberImsi OBJECT-TYPE SYNTAX DisplayString (SIZE(13..15)) MAX-ACCESS read-create STATUS current DESCRIPTION "The subscriber's IMSI." ::= { subscriberEntry 4 }
<xsd:element name="subscriberImsi" minOccurs="0"> xsd:annotation xsd:appinfo <maxAccess>read-write</maxAccess> <status>current</status> <oid>1.3.6.1.4.1.14707.1.1.6.1.1.4</oid> </xsd:appinfo> xsd:documentation The subscriber's IMSI. </xsd:documentation> </xsd:annotation> xsd:simpleType <xsd:restriction base="xsd:string"> <xsd:pattern value="(((#x00-#x7f)){13,15})"/> </xsd:restriction> </xsd:simpleType> </xsd:element>
**Also here, no "minLength" or "maxLength"...
Regards Torsten