Ticket Change Details
Not logged in
Overview

Artifact ID: 5610a331337244f3ba319e84c9b78c971dc21d8e90d104720efa1360cfbe1d5e
Ticket: 584bfb772724c1a938f671b8a9ac1d57b2d70f58
WS::Client returns nonsense for abstract types
User & Date: oehhar 2018-02-09 19:01:51
Changes

  1. Appended to comment:
    
    
    <hr /><i>oehhar added on 2018-02-09 19:01:51 UTC:</i><br />
    Gerald wrote by private mail that abstract types are supported.
    
    So look why the abstract type is not set for Envelope.
    
    (The log of loading the wsdl is 1.8GB and takes 30 Minuites to be generated... ;-)
    
    <verbatim>
    
    >>> in: parseScheme Client http://orthos.dhses.ny.gov/arcgis/services/Latest/MapServer domNode053D9940 1 serviceInfo tnsCount
     	processing domNode054299A4
    
    >>> Call 
    Entering parseComplexType Client serviceInfo 1 domNode054299A4 tns1
    Complex Type is tns1:Envelope
    *** Line 3255 -> Abstract type is detected
    	 Abstract type = true
    Complex Type is tns1:Envelope, middle is annotation
    Complex Type is tns1:Envelope, middle is complexContent
    
    *** Line 3372: complexContent case
    
    Content Type is {extension}
    
    *** Line 3400: handler for extension
    
    Calling partList for extension of tns1:Envelope
    
    >>> Call: partList mode=Client node=domNode05429A54 serviceName=1 dictVar=results tns=tns1 {occurs=""}
    Entering partList Client domNode05429A54 1 results tns1 -- for extension
    
    *** Line 3535: special treatment for extension
    
    	 base name of extension is {tns1:Geometry} with typeinfo {0 0}
    *** As Geometry is a simple type, no further processing (which looks ok)
    	 Simple type
    *** As no child nodes, a list with an empty element is returned
    <<< back
    partList for extension of tns1:Envelope is {{}}
    at end of foreach {tns1:Envelope} with {}
    Defining tns1:Envelope
    
    *** Line 3444: empty part list but abstract type
    
    *** Line 3448: As there is no partlist, a simple type is defined here for the abstract type
    
    >>> In: ServiceSimpleTypeDef Client 1 tns1:Envelope {base string comment {}} tns1 
    </verbatim>
    
    For me, it looks, like a simple type may not be abstract.
    The else case in line 3447:
    <verbatim>
        if {[llength $partList] || $isAbstractType} {
            #dict set results types $tns:$typeName $partList
            dict set results types $typeName $partList
            ::log:::log debug  "Defining $typeName"
            if {[llength $partList]  && ![string equal [lindex $partList 0] {}]} {
                ::WS::Utils::ServiceTypeDef $mode $serviceName $typeName $partList $tns $isAbstractType
            } else {
                ::WS::Utils::ServiceSimpleTypeDef $mode $serviceName $typeName [list base $defaultType comment {}] $tns
            }
    </verbatim>
    may probably only be hit by an abstract type.
    
    The abstract type information is lost (maybe not necessary for a simple type).
    
    An abstract type may be flagged by the upper if-case routine "ServiceTypeDef ".
    
    So far an analysis...
    
    Harald