Re: [Openoss-devel] Problems with Tigerstripe enum definition

[Xose R. S. V. <xr...@op...>]

For me is not clear if a new feature must be added. I have performed 
tests and I can see documentation about String enumeration in the 
schema, for example:

    <xsd:simpleType name="EquipmentSwitchReason">
    <xsd:annotation>
    <xsd:documentation>
    <p>This enumeration reflects the reason why a switch occurred.</p>
    </xsd:documentation>
    </xsd:annotation>
    <xsd:restriction base="xsd:string">
    <xsd:enumeration value="NOT_APPLICABLE">
    <xsd:annotation>
    <xsd:documentation>
    <p>NOT_APPLICABLE is used, if a more precise value is not
    available.</p>
    <p>This literal has value "NOT_APPLICABLE"</p>
    </xsd:documentation>
    </xsd:annotation>
    </xsd:enumeration>
    <xsd:enumeration value="MANUAL">
    <xsd:annotation>
    <xsd:documentation>
    <p>MANUAL indicates a switch that was requested by the operator
    and includes forced switches.</p>
    <p>This literal has value "MANUAL"</p>
    </xsd:documentation>
    </xsd:annotation>
    </xsd:enumeration>
    <xsd:enumeration value="EQUIPMENT_FAILURE">
    <xsd:annotation>
    <xsd:documentation>
    <p>EQUIPMENT_FAILURE is used when an instance of equipment has
    failed.</p>
    <p>This literal has value "EQUIPMENT_FAILURE"</p>
    </xsd:documentation>
    </xsd:annotation>
    </xsd:enumeration>
    </xsd:restriction>
    </xsd:simpleType>


As I understand the allowed enumerations is the String.

So please, could you me clarify the requirement to perform the task?

Thanks in advance

El 18/06/2012 8:22, Flauw, Marc escribió:
> Craig,
>
> This is a specificity of X.721 as some enum are state with a single value and some can have multiple values.
> Availability status has always been a set of. It is possible to have multiple values, like { Degraded, Log_Full}
>
> So it is not a model  problem.
>
> On the SOAP generator, initially only String based enum were allowed and it was late in the game that int-based were allowed. I remember we had this discussion on whether we should use the int or the corresponding string value and the result was that the string value was more useful.  But I agree the mapping between the string and the enum should be provided in the doc.
>
> The Doc Generator gives both (see picture).
>
> Best regards
>
> Marc
>
> -----Original Message-----
> From: Craig Gallen [mailto:gal...@go...] On Behalf Of Craig Gallen (opennms)
> Sent: Sunday, June 17, 2012 9:59 AM
> To: openoss-devel; Flauw, Marc; Pierre Gauthier; Xose Ramon Sousa Vazquez
> Cc: Craig Gallen (OpenNMS)
> Subject: Problems with Tigerstripe enum definition
>
> Hi,
>
> I have been trying to fix the java generation of Tigerstripe enum values and have a few questions about how the Soap generator is working which might be bugs. I also have some questions about the MPAC model.
> Craig
>
> 1. Firstly MPAC
> The following int enum variables in ItuStateAndStatusList are set to multiplicity * which does not make sense since the other enum variables in ItuStateAndStatusList are set to multiplicity 0..1 I don't understand why these are multiplicity *, Should they not be 0..1?.
>
> org.tmforum.tip.resource.res.tip.nrb.ItuStateAndStatusList.X721_AVAILABILITY_STATUS
> org.tmforum.tip.resource.res.tip.nrb.ItuStateAndStatusList.X721_CONTROL_STATUS
> org.tmforum.tip.resource.res.tip.nrb.ItuStateAndStatusList.X721_STATE
> org.tmforum.tip.resource.res.tip.nrb.ItuStateAndStatusList.X721_CONTROL_STATUS
> org.tmforum.tip.resource.res.tip.nrb.ItuStateAndStatusList.X721_CONTROL_STATUS
>
> It doest seem to make sense to have an array of constants like X721_AVAILABILITY_STATUS in this context.
>
>
> 2. Soap generator
> a) When the soap generator generates an enumeration Base Type 'int' in
> MPAC it  generates the following example from
> tip_mpac_resource_res_tip_nrb.xsd. Why is the restriction base given as
> <xsd:restriction base="xsd:string">  rather than<xsd:restriction
> base="xsd:int">  for a tigerstripe Base Type 'int'.
> Should we not be generating<xsd:restriction base="xsd:int">?
>
> b) in the generated documentation all we get is something like 'This
> literal  has  value 0'. There is no mention of the name of the value in
> the xsd. Should we not be generating documentation in the xsd which says
> LOCKED=0, UNLOCKED=2. This is a minimum requirement but In fact, there
> is an argument that we should be generating constant values which
> include the named definition.
>
> <xsd:simpleType name="AdministrativeState">
> <xsd:annotation>
> <xsd:documentation>
> <p></p>
> </xsd:documentation>
> </xsd:annotation>
> <xsd:restriction base="xsd:string">
> <xsd:enumeration value="0">
> <xsd:annotation>
> <xsd:documentation>
> <p></p>
> <p>This literal  has  value 0</p>
> </xsd:documentation>
> </xsd:annotation>
> </xsd:enumeration>
> <xsd:enumeration value="2">
> <xsd:annotation>
> <xsd:documentation>
> <p></p>
> <p>This literal  has  value 2</p>
> </xsd:documentation>
> </xsd:annotation>
> </xsd:enumeration>
> <xsd:enumeration value="1">
> <xsd:annotation>
> <xsd:documentation>
> <p></p>
> <p>This literal  has  value 1</p>
> </xsd:documentation>
> </xsd:annotation>
> </xsd:enumeration>
> </xsd:restriction>
> </xsd:simpleType>
> <xsd:complexType name="ArrayOfAdministrativeState">
> <xsd:sequence>
> <xsd:element name="item" type="tns:AdministrativeState" minOccurs="0"
> maxOccurs="unbounded"/>
> </xsd:sequence>
> </xsd:complexType>
>


-- 

*Xose Ramon Sousa Vazquez* | Director OSS Technologies, Director I+D
T/ + 34 986 410 091 (ext) 206 | M/ +34 675 550 029
www.optaresolutions.com
<http://www.optaresolutions.com>
Optare Solutions <http://optarecoolvendor.com><http://optarecoolvendor.com>