incubator-yoko-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mosur Ravi, Balaji" <>
Subject RE: Refactoring the idltowsdl tool
Date Wed, 18 Oct 2006 15:02:00 GMT
Hi matteo,

I think that is a good idea... When I first started to work on this
tool, I had thought of the visitors as you had imagined but somewhere
down the line I think it got polluted. I think what you mentioned makes
a lot of sense.

- Balaji

-----Original Message-----
From: Vescovi, Matteo 
Sent: Wednesday, October 18, 2006 10:24 AM
Subject: Refactoring the idltowsdl tool

I am trying to work out what the best approach to add support for 
anonymous types to the idltowsdl tool is.

After giving it some thought, it seems to me that a good deal of 
refactoring is neded in order to enable the idltowsdl tool to support 
the full range of IDL constructs.

Before I start working, though, I would very much appreciate some 
feedback on the changes I intend to make to idltowsdl and a reassurance 
that I am on the right track :-)

I'll try to keep this as short as I can.

I think that the main problems I am facing stem from the fact that 
original idea was to create Visitor classes that encapsulated what is 
needed to create XmlSchema or Wsdl types.

However, because the original Visitor classes focus on the resulting 
XmlSchema or Wsdl types, they cause quite a lot of code duplication. I 
believe our visitor classes should instead focus on visiting IDL grammar


An example will hopefully makes this clear: let's take the 
Its task is to visit the parameters of a IDL operation and generate the 
corresponding corba:param and wsdl:part elements.
I think its real focus should be to visit the IDL grammar construct 
(CORBA spec, chapter 3):
<parameter_dcls> ::= "(" <param_dcl> { "," <param_dcl> }* ")"
<param_dcl> ::= <param_attribute> <param_type_spec> <simple_declarator>
<param_attribute> ::= "in"
  | "out"
  | "inout"
<param_type_spec> ::= <base_type_spec>
  | <string_type>
  | <wstring_type>
  | <scoped_name>

However, because its focus is to generate wsdl message parts, it has to 
visit the return parameter too, which is a different IDL grammar rule 
<op_type_spec>. This creates a special case that needs to be handle with

care and does not fit in with the model.

A cleaner solution would be to have a ParameterDclsVisitor which visits 
a <parameter_dcls> IDL grammar rule (i.e. the AST nodes created for that

rule), which in turn invokes other visitors to visit other IDL grammar 
For example, when it gets to visiting <string_type> in 
<param_type_spec>, the StringTypeVisitor should be invoked.

Effectively, what I propose is to partition the IDL grammar rules in 
sets and have a Visitor class take care of a rule set.
This is already what we have in the idltowsdl tool, but the problem is 
that some Visitors visit overlapping rules, hence code  duplication.
For example, the TypesVisitor class contains switch statements to visit 
IDL const and IDL exception types. The same code is in the WSDLVisitor.
I think that a clean solution to this kind of problems would be to have 
WSDLVisitor to visit the IDL grammar rule:
<definition> ::= <type_dlc> ";"
  | <const_dcl> ";"
  | <except_dcl> ";"
  | <interface_dcl> ";"
  | <module_dcl> ";"

and have TypesVisitor visit <type_dlc> instead of visiting <type_spec> 
and <const_dcl> and <except_dcl> as it currently does.

But perhaps the most important advantage in taking an "IDL grammar rule"

approach is that it makes it easy to support correct IDL in general (and

anon types in particular).

I can't think of another way to support the anon types, but to mirror 
the IDL grammar rules within the visitor classes.
Provided a visitor can visit all the possible productions of the set of 
rules it implements, then we are guaranteed that it will produce the 
right XmlSchema and WSDL.

To give a better idea of the kind of changes I'd like to make, I'll 
describe the changes I started working on.

I modified the WSDLVisitor to implement the <definition> rule, so now it

will invoke the TypesVisitor to visit <type_dlc>, ConstVisitor to visit 
<const_dcl>, ExceptionVisitor to visit <except_dcl>, PortTypeVisitor to 
visit <interface_dcl>, and I am considering adding a ModuleVisitor to 
visit <module_dcl> (which would handle nested modules and building the 
a.b.c.interface dotted scoped names).

The next step would be to slightly modify the TypesVisitor to implement 
the <type_declarator> rule and all its children.
Then create a TypeDclVisitor that

So, what are your thoughts on all this?

- Matteo

View raw message