Minutes of the Woden Status Telecon, 2006-06-20

[Lawrence Mandel <lm...@ca.ibm.com>]

Attendees: Lawrence Mandel, Samuel Isokpunwu, John Kaputin, Oshani 
Seneviratne (via IRC), Arthur Ryman, Eran Chinthaka

Minutes

1. Open Action Items - Lawrence Mandel 

2006-06-13: Eran to post a summary of the scenario to woden-dev. 
Lawrence: Done. I was this was posted to Woden-dev
Closed.

2. M5 Status - John Kaputin 
John: Dims has already voted +1. We need two more incubator PMC votes. I'm 
going to post directly to Sanjiva and Paul to get their votes for M5. 

3. Interoperability Status - Lawrence Mandel 
John: Nothing new from me. I saw some notes from Arthur and Eran. I've 
left Graham to pursue this. He's going to test with the code from the 
Axis2 repository. Eran will show off Axis2/Woden at the interop event in 
July.

Lawrence: Are there any blocking issues for the interop event?
John: I need to take a closer look.
[action] Lawrence and John will review the open bugs for blocking interop 
problems.
John: I think the real important thing is to go through the W3C interop 
report and identify the cause of the failures.

Note: Arthur joined the call late. We continued the above discussion 
below.

Lawrence: Arthur, do you know if the failing Woden tests are due to 
problems with the interchange generator or with Woden?
Arthur: The failing interchange results are from problems in Woden. 
John: If there's a required extension property those classes will always 
exist.
Arthur: That's not right.
John: How do you provide a default value?
Arthur: The first concept is which extensions are supported. Woden 
supports 4 extensions. Should implement those 4. Two are tiny. One is 
safety and one is RPC signature. Two are big, SOAP and HTTP binding. 
Safety always exists (may change to optional). RPC is only present if RPC 
style is present. For bindings, HTTP binding will occur if type of binding 
is HTTP and SOAP will occur if type is SOAP. They don't both occur all the 
time. This is my interpretation of spec. There is also an extension of 
endpoint which is an HTTP extension. Even if the object only contains 
optional values it should still be created. The extension is present 
depending on the value of the type. Another problem I found, in the SOAP 
binding it reuses some properties defined by the HTTP extension. Those 
extension objects should have properties in them. The SOAP extension 
object will contain HTTP properties.

John: Another thing to consider is whether component property wrappers is 
the right way to go.
Arthur: I don't see a way around it.
John: Can do runtime checking but then no compile time checking.
Arthur: Have to specify extensions that component model interface 
supports. Can't pick out what extensions to add based on document.

Arthur: One other problem, when we use a schema location in the types 
section in theory it can be a fragment identifier. Woden currently doesn't 
use Xerces correctly so this doesn't work. See Woden-10.

4. StAX Parser Implementation - Oshani Seneviratne
Arthur: What's the benefit of StAX parsing for WSDL?
Eran: 1. Axiom performance tests should it is faster than other object 
models and consumes less memory. 2. Axis2 works with pull stream so 
integration will be easier if Woden works this way as well.
Arthur: What kind of access on the object model are you doing? If you say 
get me all the interfaces it has to get everything.
Eran: If the Woden model is completely on Axiom then even imported 
documents will only be read to the extend that we need. For code 
generation we need the whole thing.

John: Current DOM impl parses DOM into the Woden model.
Eran: So we'll replace the DOM with Axiom.
Arthur: Then you're creating a mapping from Axiom to the Woden API.
Eran: Better to implement Woden interfaces on top of Axiom. Read directly 
to the WSDL model.

Eran: Woden will affect Axis2 when deploying a service and generating a 
WSDL document from Java. If someone will access a WSDL doc during runtime 
we should use Woden.
John: So your concern is about performance not about the Xerces 
dependency.
Eran: Correct.
John: Are there any plans to remove the DOM dependency in XmlSchema?
Eran: Well we also have a DOM dependency in WSDL4J.

The following conversation took place on IRC for this item in the agenda:

[11:15AM] lmandel: OK Oshani. You're up.
[11:16AM] oshani: ok... thanks
[11:16AM] oshani: I want to know how I may get around with the 
dependencies in the *attrImpl classes?
[11:16AM] oshani: dependencies on DOM
[11:17AM] lmandel: John's going to have a quick look.
[11:17AM] oshani: Actually, I would like to know how the extension 
attribute parsing is done with the current model
[11:19AM] jkaputin: The qname of the extension attribute is registered in 
the ext registry with a XMLAttr subtype
[11:19AM] jkaputin: The XMLAttr subtype has the deserialization logic in 
its implementation
[11:20AM] oshani: could u explain what the methods init and convert try to 
do there?
[11:21AM] jkaputin: init method takes the DOM Element that contains the 
extension attribute and the QName of the extension attr and the String 
value of the ext attr...
[11:22AM] jkaputin: The convert method is implemented by the XMLAttrImpl 
subclass. It has the deserailization logic to convert the string to an 
XMLAttr object
[11:23AM] jkaputin: OK?
[11:23AM] oshani: hmm... I would have to pass an OMAttribute to the 
parseExtensionAttributes, and I'm not clear how I should proceed 
afterwards..
[11:23AM] oshani: should I try to convert the OMAttribute to a DOM 
element?
[11:25AM] lmandel: Is there some way the John, is there some way we can 
extract the info needed from the DOM element and pass that in instead of 
the DOM element?
[11:25AM] jkaputin: No I don't think so. We probably need to do something 
different with XMLAttr.init so that it is not DOM dependent. I have not 
yet considered what, though.
[11:25AM] jkaputin: Re you last question...
[11:26AM] jkaputin: The DOM element is used to resolve any namespace 
prefix included in the String value of the ext attribute
[11:26AM] oshani: when u say, something different, do u mean implement 
another init?
[11:27AM] jkaputin: Maybe it's possible to pass around just the qname of 
the parent element and let the implementation resolve this to an object 
(DOM Element or OMAttribute or whatever)
[11:28AM] jkaputin: Yes, another method signature for the init method
[11:30AM] oshani: i did not understand what u mean by "pass around the 
qname of parent..."
[11:31AM] oshani: in the case of an extension attribute, what do u 
consider as the parent?
[11:32AM] jkaputin: I meant the qname of the element that contains the 
extension attribute
[11:32AM] oshani: okay...
[11:32AM] jkaputin: Can I give this some thought offline and liaise via 
the woden-dev list or another IRC chat?
[11:32AM] oshani: sure...
[11:33AM] jkaputin: We are just having a conversation about StAX, hang on 
a moment - might have some questions for you.
[11:34AM] oshani: if it's the best option, i prefer having another method 
signatures in init and convert, which would take in OM stuff
[11:35AM] jkaputin: We realized early on that we need to eliminate or 
address DOM dependencies in the Woden API, so changing the current init 
method is probably the way to go. Just need to give it some more thought
[11:36AM] jkaputin: We probably don't want DOM-dependent and OM-dependent 
methods. Better to abstract both, I think.
[11:37AM] oshani: yes, that would be the best solution
[11:40AM] oshani: Lawrence, u told me about the need to do WSDL 2.0 
document and component validation with regards to a StAX based parser. But 
if I'm just substituting the object model, there would be no need for it, 
right?
[11:40AM] oshani: I suppose the Woden object model takes care of it
[11:42AM] oshani: At the moment, I am only validating the XML only. For 
eg. whether they are the expected children in the model
[11:43AM] oshani: is that what you meant? or is it something else?
[11:53AM] lmandel: Sorry Oshani. We're just discussing something else. 
I'll take a look at your questions in a few minutes.
[11:53AM] oshani: sure.. no problem
[12:08PM] aragorn: I like to hear an answer from  Arthur abt the interop 
question made in the list
[12:09PM] aragorn: basically to be clear abt whay exactly we should do
[12:09PM] aragorn: please s/aragorn/chinthaka
[12:43PM] lmandel: Hi Oshani. Sorry for the delay. Validation of WSDL 
consists of more than simply validating the XML elements. There are 
semantic WSDL rules that are not covered by simple XML conformance 
checking or schema validation. For example, bindings can reference 
interfaces. There is no way using schema validation to ensure the 
interface references reference defined interfaces.
[12:44PM] oshani: so, isn't the Woden model take care of that already?
[12:45PM] lmandel: The Woden model doesn't do semantic WSDL validation 
itself but rather there is a separate validation component that is called 
after the model is created to validate.
[12:46PM] lmandel: I thought you were asking what WSDL validation consists 
of. Are you asking what needs to be handled by the StAX parser?
[12:46PM] oshani: yes,
[12:47PM] oshani: and what I am doing now is take the AXIOM model of the 
WSDL and parse it into the Woden specific objects
[12:47PM] lmandel: OK. So yes. The StAX parser is responsible for XML 
conformance and schema validation.
[12:48PM] oshani: about schema validation... I am using XMLSchema for 
that, after serializing the OMElement into an InputSource
[12:49PM] lmandel: To be clear, by schema validation I don't mean 
validation of inline schemas. I mean validation of a WSDL document against 
the WSDL schema.
[12:50PM] oshani: okay
[12:50PM] lmandel: Are we on the same page?
[12:51PM] oshani: yes, it was just that I saw in some of the comments to 
support RelaxNG in the future
[12:51PM] oshani: and got bit confused I guess 
[12:51PM] lmandel: That's a different requirement. That requirement is for 
the inline types.
[12:53PM] oshani: on a different note, do u have wsdls that were tested 
for all the parsing methods?
[12:53PM] oshani: so far I only found 2 wsdls with the svn checkout
[12:54PM] lmandel: I think we're currently just using the ones in the W3C 
test suite.
[12:54PM] lmandel: (Link: 
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/index.html)http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/index.html
[12:54PM] oshani: thanks
[12:56PM] oshani: Well, I guess that's about it for the moment. Thanks a 
lot for answering my questions and clearing the doubts I had.
[12:57PM] lmandel: np. Feel free to get in touch at any time through the 
dev list for more help. If needed we can start an IRC chat.
[12:57PM] oshani: thanks again.

5. Other Business - Open 

Eran: I ran into a problem using WSDLSource.
John: Call WSDLReader createWSDLSource which will give you a WSDLSource 
object specific for DOM implementation. On WSDLSource you can set source 
and pass in DOM document, element or inputsource. Get a runtime exception 
if not one of those.
Eran: I created a WSDLSource using null.
John: There is an implementation specific for the reader type. You need to 
call the setSource method before passing it in.

John: Should we have an M6 before the interop? About a week turnaround 
time on voting.
Lawrence: I'd prefer to just have a build before the interop event, fix 
problems at the event and declare M6 after the event.


Thanks, 

Lawrence Mandel