Attendees: Arthur Ryman, John Kaputin, Graham Turrell
Apologies: Lawrence (vacation)
Minutes
1. Open Action Items - John Kaputin
none.
2. Milestone (M7) Status - John Kaputin
John: Still a lot to do although I've made some progress over the break.
The 15th is looking tight. I suggest we push the date back a week to the
Jan. 22. Dev cut will be the 15th.
Arthur: I suggest we formally declare that one of our M7 P1 items is to
fully pass on all of the good component interchange documents.
John will propose the M7 release defining criteria and date
change on the woden-dev list.
[action] John did post new date of Jan 29 to mailing list, but not the
release defining criteria. Will post criteria to the list and update
milestone plan web page with new date and criteria this week.
Graham: I've finished with the catalog stuff. I've started working on the
unit test Jiras. I'll assign these Jira to myself and handle the testing.
[closed] Graham has assigned these to himself and is working through them.
Lawrence: Woden-67 is unassigned. Should this be dropped from M7?
John: This Jira is open to split the build into DOM and StAX to reduce
dependencies. We'll produce three jars. API, DOM and StAX.
Arthur: In this case we'll have duplicate code in the DOM and StAX jars. I
think it's better to produce jars that do not overlap.
John: We can produce 4 jars. API, DOM, StAX and common. I think this is
important. I suggest we leave it on the plan and re-evaluate the
probability of this getting fixed next week.
(2006-01-09)
John: lets leave WODEN-67 on plan but as lower priority than the WSDL2 test
case JIRAs.
Arthur: I agree, priority is WSDL2 testcase JIRA to achieve finalization of
spec.
[Closed]
Discussed API changes to WSDLReader in WODEN-119 and WODEN-120
WODEN-119 is about passing wsdl uri to readWSDL methods as java.net.URI
instead of java.lang.String.
Arthur: could we just add new methods that take java.net.URI and leave the
methods with String args?
John: an original design goal was type safety in the API, so allowing only
URI args instead of String args means the user must ensure that the wsdl
uri argument is 'type safe' (i.e. in the correct format to create a
java.net.URI). It also achieves consistency across the API as everywhere
else java.net.URI is used to represent uris. The issue is not specifically
about avoiding the need to handle MalformedURLException within the reader.
Arthur: how do we handle API change without breaking existing users?
John: Add new readWSDL methods with URI args, deprecate existing methods
for M7 then remove them in the release that follows M7.
Arthur: agreed.
Graham: agreed.
Jeremy has already +1 via the mailing list.
WODEN-120 is about the readWSDL methods returning Description instead of
DescriptionElement.
We discussed the rationale as explained in the JIRA and agreed with this
proposal (John, Arthur, Graham).
Jeremy has already +1 via the mailing list.
Noted that as deprecation of existing methods won't work (i.e. it's just
the return type being changed), we will need to coordinate with Axis2 folks
on their building of a Woden SNAPSHOT jar for inclusion in the Axis2 build.
This discussion led to another discussion about how imports are handled
(see next para).
[action] John to coordinate this change with Axis2 / WSO2
We discussed 2 aspects of the handling of WSDL imports within Woden:
1. how imported WSDL is represented internally within Woden so that
<wsdl:import> elements can be resolved correctly.
2. caching strategies to improve performance where multiple document are
used, particularly in build-time environments with multi document
re-validation.
Arthur: Import relates to namespace not location, so WSDL content for each
namespace should be represented in Woden in a 'master' description doc
keyed of that namespace and any retrieved documents from that namespace
should be included in that master document. This master description is
stored in a 'catalog' keyed by NS. When a wsdl:import is processed it
should try to resolve against the catalog first, before trying to retrieve
a document. If the wsdl:import has no location attribute, this catalog is
the way to resolve the import.
John: So if a wsdl import cannot be resolve to anything (via this catalog
or externally) it is an error? At least, it results in an error if the
component model contains any components from this namespace?
Arthur: correct.
John: Currently Woden always tries to retrieve a document based on the
location attribute of a wsdl:import. It does check a cache to reuse the
DescriptionElement if the document has already been retrieved, but it does
not do anything special to resolve a wsdl import without a location
attribute. This catalog mechanism sounds like the solution.
Arthur: There are two types of catalog - one is like a caching proxy for
better performance, the other is a catalog for resolving references. We
also need a cache that stores retrieved description keyed by URL to reduce
I/O and allow one time object creation, as well as the catalog keyed by
Graham: confirmed that the existing resolver mechanism is a URL resolver
only which provides indirection between a URL and some alternative
location, but it does not provide any caching proxy type of support.
Arthur: we could 'pipeline' something with the URL resolver that does
provide the caching support, at least for documents retrieved from internet
URLs.
We agreed and accepted on the two ideas in this discussion.
[action]:John to open JIRA to handle WSDL imports correctly (eg: resolving
imports with no location attribute) and to check if a testcase exists in
the WSDL 2.0 test suite for this (assume not, as if there was one Woden
would show a failure).
We discussed John's mailing list post today about SparqlQuerySimplified-1G
testcase and the expected presence in the component model of imported
Schema components.
John: Woden is failing this testcase because the {element declarations}
does not contain an element declaration from a schema that is imported by
the inlined schema, but whose namespace is NOT imported by the <types>
element. Should {element declarations} and {type definitions} just contain
the schema components whose namespaces have been either inlined within the
<types> element or imported directly within <types>, or should it include
all global elements and types from the entire schema tree(s), including any
schema components that those schemas import?
Arthur: the latter. The component model would be invalid if in contained
some component with a QName reference that could not be resolved because
the element declaration was missing. Example, A imports B and B imports C.
B components appear in the component model along with A components and it
is valid for B components to refer to C components, so C components must
also be in the component model, even if A doesn't import the C namespace -
otherwise B's qname references cannot be resolved.
John: but it is an error for A components to refer to C components unless
it import C namespace?
Arthur: correct. This argument applies to WSDL imports too, not just schema
imports.
[action] agreed, John will reply to his mailing list post to confirm this
understanding and close the issue.
Arthur raised topic of using "component handles".
Arthur: The Component API should return component handles as well as or
instead of component references. A component handle has a QName and a
reference to the object that the QName resolves to.
John: so a null reference in the handle indicates that the QNames could not
be resolved, but the handle still shows you what the QName was?
Arthur: yes.
John: Currently in the Component API getters you get a reference to the
component. If the qname is not resolve, null is returned. To see what the
QName was you have to go to the Element API by calling toElement() on the
component. A component handler provides both the identifier (qname) and the
object reference.
Arthur described how this might be used to process WSDL in phases, first
one document at a time, then resolve references between them. Used the
compile/link approach as an analogy.
3.Development Discussion - All
4. Other Business - All
regards,
John Kaputin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
