axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Franz Fehringer <>
Subject Re: handling of xml attributes flawed
Date Wed, 05 Jul 2006 16:04:45 GMT
Hello Adrian,

I looked into the relevant Java sources, but need some help for 
understanding and making progress.
I start with ParamWriter, which ist the base class of ParmHeaderFileWriter.
The latter class is used for generating the header files (at least in my 
C++/document/literal/wrapped case).
ParamWriter is constructed from a WebServiceContext and a Type.
Each Type contains hashes and vectors of both elements and attributes.
What is now a great source of confusion is, that the concepts of 
elements and attributes are freely intermixed (perhaps the author got 
himself confused regarding XML attributes versus struct/class attributes).
The ParmWriter class has only an AttributeInfo array and no ElementInfo 
Consequently both attributes and elements are stored in the 
AttributeInfo array, which is populated with populateAttribList().
This method seemingly relies on Type having full information about the 
present attributes and elements.
What i wonder now is

    * Are ElementInfos for XML elements and AttributeInfos for XML
      attributes or is this a misunderstanding on my side?
    * In class Type elements maps names to ElementInfos, whereas
      attributes maps names to Types.
      Why not map names to AttributeInfos in the latter case?
      This seems to be the principal flaw to me; there is no direct
      access to the attributes and their properties (isOptional for
      example) in populateAttribList; only elements can be accessed with
      their properties.

Now that my email has become enough confusing too, i think i will give 
it a second try tomorrow.
As a last try for today are the following ideas sound?

    * AttributeInfos should be constructed from names and types like
      ElementInfos (for attributes a simpler type concept than Type
      would be sufficient).
    * If className (currently constructor argument for AttributeInfo) is
      needed for source generation, it should be in the base class
    * In class Type, the attributes member should be a map from String
      to AttributeInfo.



Adrian Dick schrieb:
> Hi,
> There are several areas where Axis C++ does not (yet) completely support
> the SOAP/XSD specs, and XML attributes is one of those.
> I raised Jira AXISCPP-716 (
> ) for the specific issue
> you've highlighted of required and optional.
> Regretably, other priorities have prevented me from fixing this problem,
> and it looks unlikely I'll have an opportunity any time soon.
> Of course, there's no reason why someone else couldn't take it on.
> As for how to fix this.
> I believe most (possibly all) the logic for this needs to be in the WSDL2Ws
> generate code.  I would suggest required attributes should be by-value
> while optional attributes should be by-pointer, similar to nillable and
> optional elements.
> Regards,
> Adrian
> _______________________________________
> Adrian Dick (
> Franz Fehringer <> wrote on 21/06/2006 10:21:51:
>> Hello,
>> Today i had a closer look at the handling of xml attributes in Axis
>> generated C++ code (i work with latest SVN and consider for the moment
>> only the deserializing/response handling part).
>> First it seems that no difference between optional and required
>> attributes is made.
>> When it comes to deserializing, it is (equal in both cases) checked if
>> the attribute is present and only in this case the appropriate setter is
>> called.
>> The problem is now, that the C++ struct members representing the
>> attributes are values and not pointers and that there is no else branch
>> in the test for presence of the attribut.
>> The net effect is, that for nonpresent attributes the correspondent
>> struct members end up uninitialized (int value 4207536 for example) ant
>> there is no way to detect the case of missing optional attributes.
>> A simple (hopefully not too simple minded) fix would be to represent all
>> attributes as pointers and setting them to NULL in the (to be created)
>> else branch.
>> Thoughts (and btw ist there already a JIRA for this)?
>> Greetings
>> Franz
>> [attachment "feh.vcf" deleted by Adrian Dick/UK/IBM]
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message