You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@axis.apache.org by Franz Fehringer <fe...@isogmbh.de> on 2006/07/05 18:04:45 UTC
Re: handling of xml attributes flawed
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
array.
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
ParamInfo.
* In class Type, the attributes member should be a map from String
to AttributeInfo.
Thoughts?
Franz
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 (
> http://issues.apache.org/jira/browse/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 (adrian.dick@uk.ibm.com)
>
>
> Franz Fehringer <fe...@isogmbh.de> 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: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
Re: handling of xml attributes flawed
Posted by Franz Fehringer <fe...@isogmbh.de>.
Hello Adrian,
Thanks for your explanations.
I made local changes which essentially deems all attributes optional.
For this i had to hack a significant amount of if statements to get a
halfway reasonable code generation.
I think this is way to crude to be of general interest and i have
presently no more time to spend on this.
But perhaps Nadir comes to the rescue?
Greetings
Franz
Adrian Dick schrieb:
> Franz,
>
> This is an area of code I haven't worked with for a little while now, so my
> knowledge is a bit rusty, but I shall try and give some responses to your
> questions below.
>
> Are ElementInfos for XML elements and AttributeInfos for XML
> attributes or is this a misunderstanding on my side?
> --> While I believe this was the original intent, taking a look
> at the code it appears these concepts have become clouded as
> the code has evolved -- although everytime I work in this area
> I try to improve it a little.
> In class Type elements maps names to ElementInfos, whereas
> attributes maps names to Types.
> Why not map names to AttributeInfos in the latter case?
> --> I have a suspicion this could be because all (xml) elements
> are stored in the typemap, so you use the name to lookup the
> needed type, while attributes are not.
> 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.
> --> It does seem odd that we immediately work with the Type
> while being able to work with AttributeInfo, that has already
> been processed to give easy access to the desired properties,
> would probably make more sense.
> 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
> ParamInfo.
> --> This does seem odd, particularly as the classname used is
> actually the one from the parent ParamInfo -- it really isn't
> obvious to me how this is used.
> In class Type, the attributes member should be a map from
> String to AttributeInfo.
>
> Regards,
> Adrian
> _______________________________________
> Adrian Dick (adrian.dick@uk.ibm.com)
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>
>
Re: handling of xml attributes flawed
Posted by Adrian Dick <ad...@uk.ibm.com>.
Franz,
This is an area of code I haven't worked with for a little while now, so my
knowledge is a bit rusty, but I shall try and give some responses to your
questions below.
Are ElementInfos for XML elements and AttributeInfos for XML
attributes or is this a misunderstanding on my side?
--> While I believe this was the original intent, taking a look
at the code it appears these concepts have become clouded as
the code has evolved -- although everytime I work in this area
I try to improve it a little.
In class Type elements maps names to ElementInfos, whereas
attributes maps names to Types.
Why not map names to AttributeInfos in the latter case?
--> I have a suspicion this could be because all (xml) elements
are stored in the typemap, so you use the name to lookup the
needed type, while attributes are not.
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.
--> It does seem odd that we immediately work with the Type
while being able to work with AttributeInfo, that has already
been processed to give easy access to the desired properties,
would probably make more sense.
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
ParamInfo.
--> This does seem odd, particularly as the classname used is
actually the one from the parent ParamInfo -- it really isn't
obvious to me how this is used.
In class Type, the attributes member should be a map from
String to AttributeInfo.
Regards,
Adrian
_______________________________________
Adrian Dick (adrian.dick@uk.ibm.com)
---------------------------------------------------------------------
To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: axis-c-dev-help@ws.apache.org
Re: handling of xml attributes flawed
Posted by Franz Fehringer <fe...@isogmbh.de>.
Hello,
My posting is admittedly nor very readable, but would it be possible to
comment at least at the three points at the end?
The problem pertains to AXISCPP-716 (info by Adrian) btw.
Thanks and best regards
Franz
Franz Fehringer schrieb:
> 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 array.
> 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
> ParamInfo.
> * In class Type, the attributes member should be a map from String
> to AttributeInfo.
>
> Thoughts?
>
> Franz
>
> 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 (
>> http://issues.apache.org/jira/browse/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 (adrian.dick@uk.ibm.com)
>>
>>
>> Franz Fehringer <fe...@isogmbh.de> 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: axis-c-dev-unsubscribe@ws.apache.org
>>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: axis-c-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: axis-c-dev-help@ws.apache.org
>>
>>
>