IMPLIED keyword for indices in xsd output
Hello all,
In the following example mib, it seems as though the parser is ignoring the "IMPLIED" keyword. I can not find any reference to it in the .xsd output. Any thoughts?
Thanks, Gerry
tradiusSvrAuthClientEntry OBJECT-TYPE SYNTAX TradiusSvrAuthClientEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry (conceptual row) representing the information of a server in a a different realm to which this server proxy forwards authentication requests." INDEX { IMPLIED tradiusSvrAuthClientName } ::= { tradiusSvrAuthClientTable 1 }
TradiusSvrAuthClientEntry ::= SEQUENCE { tradiusSvrAuthClientName DisplayString, tradiusSvrAuthClientRowStatus RowStatus, tradiusSvrAuthClientOperState TradiusRowOperState, }
tradiusSvrAuthClientName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS not-accessible STATUS current DESCRIPTION "The DNS name or IP address of the client" ::= { tradiusSvrAuthClientEntry 1 }
Hi!
Gerry> In the following example mib , it seems as though the Gerry> parser is ignoring the "IMPLIED" keyword. I can not find any Gerry> reference to it in the .xsd output. Any thoughts?
Good point. Torsten, how do you think about adding an according construct to such entries' <appinfo> elements?
-frank
On Mon, Feb 03, 2003 at 04:58:42PM +0100, Frank Strauss wrote:
Gerry> In the following example mib , it seems as though the Gerry> parser is ignoring the "IMPLIED" keyword. I can not find any Gerry> reference to it in the .xsd output. Any thoughts?
Good point. Torsten, how do you think about adding an according construct to such entries' <appinfo> elements?
Good idea. I have added an <appinfo> element called <implied> that has the value <implied>true</implied> if the IMPLIED keyword is present and <implied>false</implied> otherwise.
Torsten
Hi!
Gerry> In the following example mib , it seems as though the Gerry> parser is ignoring the "IMPLIED" keyword. I can not find any Gerry> reference to it in the .xsd output. Any thoughts?
Good point. Torsten, how do you think about adding an according construct to such entries' <appinfo> elements?
Torsten> Good idea. I have added an <appinfo> element called <implied> Torsten> that has the value <implied>true</implied> if the IMPLIED Torsten> keyword is present and <implied>false</implied> otherwise.
Thanks for the quick update. I spent a look on the currently generated output and more thoughts on this kind of flag information (and I'm sorry for not doing this in the first place before you spent work on it).
First, I propose to supply this new information only on the elements that represent a row type, i.e. not for columnar or other scalar elements.
Furthermore, there is another kind of flag information that is still missing (which I did not recognize earlier): we do not yet signal in the XSD output whether writable columnar elements (i.e., those with <maxAccess>read-write</maxAccess>) are just writeable or also creatable. Hence, I suggest to denote these two kinds of flags together as <flags [implied="yes|no"] [create="yes|no"]/>, where the default "no" can be omitted and if both flag values are "no" the whole <flags> element can be omitted. I think this can be mapped quite straight forward from smi.h::SmiNode.
-frank
On Mon, Feb 03, 2003 at 08:36:30PM +0100, Frank Strauss wrote:
First, I propose to supply this new information only on the elements that represent a row type, i.e. not for columnar or other scalar elements.
Furthermore, there is another kind of flag information that is still missing (which I did not recognize earlier): we do not yet signal in the XSD output whether writable columnar elements (i.e., those with <maxAccess>read-write</maxAccess>) are just writeable or also creatable. Hence, I suggest to denote these two kinds of flags together as <flags [implied="yes|no"] [create="yes|no"]/>, where the default "no" can be omitted and if both flag values are "no" the whole <flags> element can be omitted. I think this can be mapped quite straight forward from smi.h::SmiNode.
OK. Furthermore, I have moved some appinfos. The appinfos for rows do not belong to the <complexType> definition anymore. They are now part of the <element> declaration.
Regards Torsten
Hi!
Torsten> OK. Furthermore, I have moved some appinfos. The appinfos for Torsten> rows do not belong to the <complexType> definition Torsten> anymore. They are now part of the <element> declaration.
Great. I've just updated the anonymous CVS repository accordingly.
-frank
participants (3)
-
Frank Strauss -
Gerry Buteau -
Torsten Klie