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 Mon, 10 Jul 2006 12:19:16 GMT
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?



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 (
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message